System Recovery

 

 

This chapter describes how to recover a system after it has failed to complete a reboot following a power off cycle or interruption of the normal boot sequence following a reload command.

This chapter includes the following sections:

•	Prerequisites

•	Accessing the boot CLI

•	Booting from a Selected Image

Caution: This system recovery process interrupts subscriber service by dropping any existing flows and preventing traffic from being processed during the boot interval. It should only be initiated as an emergency measure.

Prerequisites

Successful recovery from a failed reboot requires that you have access to the system via a console port, and have an uncorrupted copy of the StarOS boot image file stored in flash memory on the SMC, or accessible from an external PCMCIA memory device.

Console Access

The boot recovery sequence can only be executed via a terminal connected to the serial console port on the active SPIO card. This connection can be through a terminal server that is accessible via a LAN interface.

The boot recovery sequence can only be viewed via the console port.

Boot Image

The boot recovery command line interface allows you to specify from which boot image you would like to boot the system. If the system failed to reload following a software update, you can initiate a boot from a previously stored image.

The system recovery procedure will prompt you to enter the path name for the location of the StarOS boot image from which the system will boot. By default the boot command will timeout and attempt to reload the highest priority image from flash memory using the default configuration file.

A boot image binary file name uses the following format:

production.build_number.asr5000.bin

Refer to the Configuring the Boot Stack section in the Software Management Operations chapter for additional information on boot stack entries and prioritization.

 

Accessing the boot CLI

To access the boot CLI you must interrupt an in-progress reload (reboot) sequence.

Caution: This system recovery process interrupts subscriber service by dropping any existing flows and preventing traffic from being processed during the boot interval. It should only be initiated as an emergency measure.

Initiate a Reboot

A reload can be initiated in one of two ways:

•	Power cycle the chassis – Turn the circuit breakers on the power filter units (PFUs) Off (0) and then On (I).

•	Execute a reload command

[local]asr5000# reload -noconfirm

The boot sequence displays messages on the terminal as it steps through its processes.

Interrupt the Boot Sequence

When the “Booting priority” message line appears (and not before), press CTRL+C to break out of the boot process as shown in the example below:

Booting priority 8

image : /flash/production.35272.st40.bin

config: /flash/system.cfg

Entry at 0x000000000cba45e0

Press CTRL+C at this point in the sequence.

A message similar to the following appears after the boot process has been interrupted:

*******9/0 Ctrl-C Pressed-------------------------------------------------------

Failed.

aborted by user

8/0:boot>

 

Enter CLI Mode

With the boot prompt displayed, enter cli to access the boot recovery CLI. The CLI prompt changes as shown below:

8/0:boot>cli

8/0:cli>

boot Command Syntax

The boot recovery command has the following syntax:

boot [ -show | -priority=* | -config=* | -noconfig ] { bootfile_URL }

The options for this command include:

•	-show: displays the current boot configuration

•	-priority=*: selects the desired boot stack priority (*)

•	-config=*: enters the desired configuration filename (*), if not the default file

•	-noconfig: boots using no configuration file

bootfile_URL is the URL for the location of the StarOS boot image file. It specifies the path and file name of the StarOS .bin file from which the system will be booted.

The URL may refer to a local file (flash) or an external file on a PCMCIA device attached to the SMC. The URL must be entered in the following format:

{ /flash | /pcmcia1 /<filename>

Booting from a Selected Image

You will issue a boot command via the boot CLI to initiate the system recovery process.

Boot Using No Configuration FIle

This procedure boots the system using the specified boot image without also loading a configuration file. A sample command string appears below:

8/0:cli>boot -noconfig /flash/production.41731.asr5000.bin

The boot sequence ends with a prompt to enter the Quick Setup Wizard for creating a configuration file.

Launching StarOS

Starting program at 0x0000000000100000

Starent Networks ASR5000 Intelligent Mobile Gateway

SMC is starting up..............................

Starting software <version> <build_number>...

No configuration found, press enter to continue.

1. Do you wish to continue with the Quick Setup Wizard[yes/no]:

You can exit the Quick Setup Wizard by entering no in response to the above prompt. Load a desired configuration file using the Exec mode configure command followed by the URL for the configuration file as shown in the example below:

[local]asr5000# configure /flash/system.cfg

Boot Using A Specified Configuration File

This procedure boots the system using the specified boot image and configuration file. A sample command string appears below:

8/0:cli>boot -config=/flash/system.cfg /flash/production.41731.asr5000.bin

The boot sequence ends with the appearance of the CLI prompt.

[local]asr5000#

Confirm that the desired configuration has loaded by running the Exec mode show configuration command.

 

 

Appendix A
Engineering Rules

 

 

This appendix provides engineering guidelines for configuring the system to meet network deployment requirements.

This appendix consists of the following topics:

•	CLI Session Rules

•	Interface and Port Rules

•	Packet Processing Card Rules

•	Context Rules

•	Subscriber Rules

•	Service Rules

•	Access Control List (ACL) Engineering Rules

CLI Session Rules

Multiple CLI session support is based on the amount of available memory. The Resource Manager reserves enough resources to support a minimum of six CLI sessions at all times. One of the six sessions is further reserved for use exclusively by a CLI session on an SPIO serial interface.

Additional CLI sessions beyond the pre-reserved limit are permitted if sufficient SMC resources are available. If the Resource Manager is unable to reserve resources for a CLI session beyond those that are pre-reserved, users with administrator-privileges are prompted to create the new CLI session, even without reserved resources.

Interface and Port Rules

The rules discussed in this section pertain to the following Ethernet line cards and their interfaces regardless of the application.

•	Fast Ethernet 10/100 (FELC/FLC2)

•	Gigabit Ethernet 1000 (GELC/GLC2)

•	Quad Gigabit Ethernet (QGLC)

•	10 Gigabit Ethernet Line Card (XGLC)

Line Card Rules

The following engineering rules apply to the Fast Ethernet 10/100, Gigabit Ethernet 1000, Quad Gigabit Ethernet and 10 Gigabit Ethernet line cards:

•	Give all logical interfaces a unique name to identify the interface from others in the same context. Logical interfaces in different contexts may have the same name.

•	A single physical port can support multiple logical interfaces when you configure VLAN tags for that physical port. You can use VLAN tagging to bind a single physical port to multiple logical interfaces that reside in different contexts.

•	Assign all logical interfaces a valid IP address and subnet.

•	Give each logical interface within a context a unique IP address(es). Logical interfaces in different contexts can have the same IP address(es).

•	If multi-homing is supported on the network, you can assign all logical interfaces a single primary IP address and up to 16 secondary IP addresses.

•	You can configure a logical interface in only one context, but you can configure multiple interfaces (up to 512 Ethernet or 1,024 ATM) in a single context.

•	You can apply a maximum of 128 access control list (ACL) rules to a single logical interface.

•	All ports are identified by their <slot#>/<port#>.

•	Each physical port on a Gigabit Ethernet 1000 or Quad Gigabit line card may contain up to a maximum of 1024 VLAN tags.

•	Each physical port on an Fast Ethernet 10/100 Line card may contain up to a maximum of 256 VLAN tags.

•	The total number of VLANs untagged and/or tagged on each Fast Ethernet 10/100 Line Card must not exceed 1025 (8 untagged + 1017 tagged).

•	A logical interface is limited to using a single VLAN or ATM PVC on a single physical port, identified by its <cardslot#/port#>.

•	When using redundant (standby) line cards:

•	You must configure the active line card only. In the event of a failover, all relevant information (including the IP address) is transferred to the standby line card.

•	Half-height line cards must installed in the upper and lower chassis slots behind a sa packet processor card must be of the same type: FELC/FLC2,GELC/GLC2, or QGLC line cards.

Important: If you have enabled the Port Redundancy feature, it is possible for ports on both line cards to be active while one provides line card redundancy for the other. With the port redundancy feature, each physical port has a primary MAC address. Each corresponding standby port has a different (alternate) MAC address.

Packet Data Network (PDN) Interface Rules

The following engineering rules apply to the interface to the packet data network (PDN):

•	Configure the logical interfaces used to facilitate the PDN interface within the egress context.

•	The default is to use a single interface within the egress context to facilitate the PDN interface.

•	You can configure multiple interfaces in the egress context by using static routes or dynamic routing protocols.

•	You may also configure next-hop default gateways.

Packet Processing Card Rules

The following engineering rules apply to the packet processing application cards:

•	Configure a line card to enter the active mode results in the following:

•	The total number of packet processing cards that will become operationally active is increased by one.

•	In the event of a failure, the line card(s) directly behind the packet processing cards will become available directly, or to another packet processing cards via the RCC.

•	If you want processing-only application cards, all line card slots directly behind the such cards can be empty. Otherwise, disable those line card slots with the shutdown command described in the Command Line Interface Reference.

•

If you want standby (redundant) PSCs or PSC2s, do not populate all line card slots directly behind them since they will not be used. If the slots are populated, disable the line card slots with the shutdown command as described in the Card Configuration Mode Commands section of the Command Line Interface Reference.

•	A line card is will not handle subscriber traffic unless the packet processing card directly in front of it is made active.

Context Rules

•	A maximum of 64 contexts may be configured per chassis.

•

Up to 2000 IP address pools can be configured within a single context (regardless of the number of packet processing cards with a total system limit of 5,000 IP address pools for all contexts. However, there is also a limit of 4,000,000 addresses and 32,000,000 static addresses that can be configured per context. Therefore, the number of pools depends on how many addresses are being used and how they are subnetted.

•	Each context supports up to 32,000,000 static IP pool addresses. You can configure a maximum total of M64 x 32M static IP pool addresses per chassis. Each static IP pool can contain up to 500,000 addresses.

•	Each context supports up to 4,000,000 dynamic IP pool addresses. You can configure a maximum total of 4 x 4M dynamic IP pool addresses per chassis. Each dynamic IP pool can contain up to 500,000 addresses.

Important: Each address in the pool requires approximately 60 bytes of memory. The amount of memory required, however, depends on a number of factors such as the pool type, and hold-timer usage. Therefore, in order to conserve available memory, you may need to limit the number of pools depending on the number of addresses to be configured and the number of installed application cards.

•	A maximum of 1,000,000 IP addresses per chassis can be in use at any given time. The maximum number of simultaneous subscriber sessions is controlled by the installed capacity license for the service(s) supported.

•	The maximum number of static routes that can be configured per context is 1200.

•	The maximum number of static ARP entries per context is 128.

•	The maximum number of domains per context is 2,048.

•	ASN GW services configured within the same context cannot communicate with each other.

•	A maximum of 512 BGP/AAA monitors can be configured per context for Interchassis Session Recovery support.

•	You can configure up to 128 AAA servers per context for a default AAA server group. The servers can be configured as accounting, authentication, charging servers, or any combination thereof.

•	You can configure up to 800 AAA server groups per context with following limitations:

•	Configure up to 128 servers per AAA server group. The servers can be configured as accounting, authentication, or charging servers, or any combination thereof.

•	Configure up to 1,600 servers per context in AAA Server group mode. The servers can be configured as accounting, authentication, or charging servers, or any combination thereof.

•	Up to 800 NAS-IP address/NAS identifier (1 primary and 1 secondary per server group) can be configured per context.

•	Up to 12 charging gateway functions (CGFs) for GTPP accounting can be configured per context.

Subscriber Rules

The following engineering rules apply to subscribers configured within the system:

•	Configure a maximum of 2,048 local subscribers per context.

•	You may configure attributes for each local subscriber.

•

The system creates a default subscriber default for each context when the context is made. Configure attributes for each default subscriber. If a AAA-based subscriber is missing attributes in the authentication reply message, the default subscriber attributes in the context where the subscriber was authenticated are used.

Important: Default is not used when local authentication (for local subscribers) is performed.

•	Configure default subscriber templates on a per AAA realm (domain aliases configured within a context) basis.

•	Configure default subscriber templates on a per PDSN, FA, ASN-GW, or HA service.

•	For AAA authenticated subscribers, the selection of local subscriber template to use for setting attributes is in the following order:

•	If the username (NAI) matches any local domain name and the domain name has a local subscriber name configured, that local subscriber template is used.

•	If the first case fails, and if the serving service has a default username configured, that subscriber template is used.

•	If the first two cases fail, the default subscriber template in the AAA context is used.

Service Rules

The following engineering rules apply to services configured within the system:

•	Configure a maximum of 256 services (regardless of type) per system.

Caution: Large numbers of services greatly increase the complexity of management and may affect overall system performance. Therefore, you should not configure a large number of services unless your application absolutely requires it. Please contact your Cisco service representative for more information.

•	The total number of entries per table and per chassis is limited to 256.

•

Although you can use service names that are identical to those configured in different contexts on the same system, this is not a good practice. Services with the same name can lead to confusion and difficulty in troubleshooting problems, and make it difficult to understand the output of show commands.

Access Control List (ACL) Engineering Rules

The following rules apply to Access Control Lists:

•	The maximum number of rules per ACL is 128.

•	The maximum number of ACL rules applied per port is 128.

•	The maximum number of ACL rules applied per context is 1024.

•	The maximum number of ACL rules per IPSec policy is 1.

•	The maximum number of IPSec ACL rules per context is 1024.

•	The maximum number of ACLs you can configure per context is limited by the number of rules allowed within each ACL. If each ACL contained the maximum number of rules (128), the maximum number of ACLs per context is 8 (128 X 8 ACLs = 1024 ACL rules per context).

•	The maximum number of ACLs applied to an IP access group is 1 whether it is configured for a port or context. Since the maximum number of IP access groups you can apply to an interface or context is 16, the following calculations apply:

•	For each interface/port: 8 rules per ACL multiplied by 16 IP access groups = 128 (the ACL rules limit per port)

•	For each context: 64 rules per ACL multiplied by 16 IP access groups = 1024 (the ACL rules limit per context)

 

 

Appendix B
System Software Task and Subsystem Descriptions

 

 

This appendix describes the system and subsystem tasks running under StarOS on an ASR 5000 platform.

It includes the folloiwng sections:

•

Overview

•	Primary Task Subsystems

•	Primary Subsystem Controllers and Managers

Overview

For redundancy, scalability and robust call processing, StarOS is divided into a series of tasks that perform specific functions. These tasks communicate with each other as needed to share control and data signals. As a result, system processes can be distributed across multiple tasks thus reducing the overall work-load on any given task and improving system performance. This distributed design provides fault containment that greatly minimizes the impact to processes or sessions due to a failure.

All tasks run in a Common Firmware Environment (CFE) that resides on specialized Central Processing Units (CPUs) on each of the application cards. The System Management Cards (SMCs) each have a single CPU that is responsible for running tasks related to system management and control. The packet processing cards (PSCn, PPC) contain two CPUs (CPU 0 and CPU 1). These CPUs are responsible for session processing and running the various tasks and processes required to handle mobile data calls. In addition to the CPUs, the packet processing cards each have a Network Processor Unit (NPU) for IP forwarding.

The following sections describe the primary tasks that are implemented by the system:

•	Primary Task Subsystems

•	Primary Subsystem Controllers and Managers

Primary Task Subsystems

The individual tasks that run on the CPUs are divided into subsystems. Following is a list of the primary subsystems responsible for call session processing:

•	System Initiation Task (SIT): This subsystem starts tasks and initializes the system. This includes starting a set of initial tasks at system startup time (static tasks), and starting individual tasks on demand at arbitrary times (dynamic tasks).

•

High Availability Task (HAT): With the Recovery Control Task (RCT) subsystem, the HAT subsystem maintains the operational state of the system. HAT monitors the various software and hardware components of the system. If there are unusual activities, such as the unexpected termination of another task, the HAT subsystem takes a suitable course of action, such as triggering an event to the RCT subsystem to take corrective action or to report the status. The end result is that there is minimal or no impact to the service.

•	Recovery Control Task (RCT): This subsystem executes a recovery action for any failure that occurs in the system. The RCT subsystem receives signals from the HAT subsystem (and in some cases from the NPU subsystem) and determines what recovery actions are needed.

The RCT subsystem runs on the active SMC and synchronizes the information it contains with the RCT subsystem on the standby SMC.

•	Shared Configuration Task (SCT): This subsystem provides a facility to set, retrieve, and receive notification of system configuration parameters. The SCT is mainly responsible for storing configuration data for the applications that run on the system.

The SCT subsystem runs only on the active SMC and synchronizes the information it contains with the SCT subsystem on the standby SMC.

•

Resource Management (RM): This subsystem assigns resources, such as CPU loading and memory, for every system task upon start-up. The RM subsystem monitors resource use to verify that allocations are as specified. RM also monitors all sessions and communicates with the Session Controller to enforce capacity licensing limits.

•	Virtual Private Network (VPN): This subsystem manages the administrative and operational aspects of all VPN-related entities in the system. The functions performed by the VPN subsystem include:

•	Creating separate VPN contexts

•	Starting the IP services within a VPN context

•	Managing IP pools and subscriber IP addresses, and distributing the IP flow information within a VPN context.

All IP operations within the system are done within specific VPN contexts. In general, packets are not forwarded across different VPN contexts. The only exception currently is the Session subsystem.

•	Network Processing Unit (NPU): This subsystem is responsible for the following:

•	Using the database to match address and port numbers to destination tasks for fast-path forwarding of dataframes

•	Receiving and transmitting user data frames to/from various physical interfaces

•	IP forwarding decisions (both unicast and multicast)

•	Per-interface packet filtering

•	Traffic management and traffic engineering

•	Passing user data frames to/from packet processing car CPUs

•	Modifying, adding, or stripping datalink/network layer headers

•	Recalculating checksums

•	Maintaining statistics

•	Managing external Ethernet interfaces

•

Card/Slot/Port (CSP): Coordinates the events that occur when any card is inserted, locked, unlocked, removed, shutdown, or migrated. SCP also performs auto-discovery and configures ports on a newly-inserted line card. It determines how line cards map to packet processing cards (through a Redundancy Crossbar Card [RCC], if necessary).

The CSP subsystem runs only on the active SMC and synchronizes the information it contains with the SCT subsystem on the standby SPC/SMC. It is started by the SIT subsystem and monitored by the HAT subsystem.

•	Session: Performs high-touch processing of mobile subscribers’ packet-oriented data session flows. High-touch user data processing consists of the following:

•	Payload transformation

•	Filtering and scheduling

•	Statistics collection

•

Policing

Primary Subsystem Controllers and Managers

Many of the primary subsystems are composed of critical tasks—controller tasks called Controllers, and subordinated tasks called Managers. Critical tasks are essential to the system’s ability to process calls, such as those in the SIT subsystem.

Controllers serve several purposes:

•	They monitor the state of their Managers and allow communication between Managers within the same subsystem.

•	They enable inter-subsystem communication since they can communicate with the controllers of other subsystems.

•	They masks the distributed nature of the software from the user allowing for ease of management.

Managers manage resources and mappings between resources. In addition, some managers are directly responsible for call processing.

The following section provides information about the composition of the primary subsystems that are composed of critical, controller, and / or manager tasks.

ASR 5x00 Subsystems

The following tables describe managers and tasks performing within the specified subsystems on an ASR 5x00 platform.

Important: Variations regarding how the managers and tasks are distributed based on session recovery (SR) are included in the Card and CPU columns in some tables. Tables without these indicators are applicable to ASR 5x00s with and without session recovery. The ASR 5x00 dynamically distributes processes, tasks, and managers on startup. The following tables list the typical locations but variations can occur depending on available resources.

ASR 5x00 System Initiation Subsystem

Task	Description	Card	CPU
SITMAIN	Initiated at system start-up, the SITMAIN task performs the following functions: • Reads and provides startup configuration to other SIT components. • Starts SITREAP sub-function. • Maintains CPU state information.	All	All
SITPARENT sub-function	• Starts SMCs in either active or standby mode. • Registers tasks with HAT task. • Notifies CSP task of CPU startup completion.	All	All
SITREAP sub-function	Shuts down tasks as required.	All	All

‌

ASR 5x00 High Availability Subsystem

Task	Description	Card	CPU
HAT System Controller (HATSYSTEM)	This is the main HAT task that will control all the HAT sub-function tasks in the system. It is initiated on system start-up and performs the following functions: • Initializes system components (such as the Gigabit Ethernet switches and switch fabric). • Monitors system components such as fans for state changes. • Triggers actions for redundancy in the event of fault detection. The HAT subsystem on the redundant SMC mirrors the HAT subsystem on the active SMC.	SMCs	0
HATCPU	• Performs device initialization and control functions because of the CPUs hardware capabilities. • Reports the loss of any task on its CPU to HATSYSTEM sub-function. • Initializes and monitors the dedicated hardware on packet processing cards.	All packet processing cards	0
	• Collects CPU monitoring information periodically and reports to the master HATCPU sub-function. • Reports the loss of any task on its CPU to the master HATCPU sub-function.	All packet processing cards	ALL
	• Performs device initialization and control functions because of the CPU’s hardware capabilities. • Reports the loss of any task on its CPU to HATSYSTEM sub-function. • Controls the LEDs on the SMC. • Initializes and monitors the dedicated hardware on the SMCs.	SMCs	0

‌

ASR 5x00 Resource Manager (RM) Subsystem

Task	Description	Card	CPU
Resource Manager Controller (RMCTRL)	Started by the SITPARENT task on system startup, and monitored by the HAT task for a failure, the RMCTRL performs the following functions at startup: • Initializes resources such as CPUs and memory. • Requests updated card status from the CSP subsystem and updates the system card table. • Communicates with all RMMGRs to request their most recent set of resource data.	Active SMC	0
Resource Manager Managers (RMMGRs)	Started by the SITPARENT task, and monitored by the HAT tasks for failures, each RMMGR performs the following functions at startup: • Initializes the local resource data and local resource scratch space. • Communicates with the SIT task on the local CPU to get its entire task table and the resources associated with each task. • Gathers current resource utilization for each task. • Sends the resource data to the RMCTRL task.	All	All

‌

ASR 5x00 Virtual Private Networking (VPN) Subsystem

		Card		CPU
Task	Description	w/o SR	w/ SR	w/o SR	w/ SR
VPN Controller (VPNCTRL)	Created at system start-up, the VPN Controller: • Initiates the VPN Manager for each context • Informs the Session Controller task when there are additions or changes to contexts. • Routes context specific operation information to the appropriate VPN Manager. • Performs VPN Manager recovery and saves all VPN related configuration information in the SCT task. Only one Session Controller operates at any time.	Active SMC	Active SMC	0	0
VPN Manager (VPNMGR)	One VPN manager is started by the VPN Controller for each configured context (one is always present for the local context) and performs the following functions: • Performs IP address pool and subscriber IP address management. • Performs all the context specific operations including but not limited to: UCM services, IP interfaces, the Address Resolution Protocol (ARP), IP address pool management, slow path forwarding, NPU flows, port Access Control Lists (ACLs), and logging. • Provides IP interface address information for each context to the Session Controller.	Active SMC (local context)	Active SMC (local context)	0 (all contexts)	0 (local context)
Border Gateway Protocol (BGP)	The BGP task is created by the VPN Manager for each context that has enabled the BGP routing protocol (router bgp config-context CLI command). The BGP task is responsible for learning and redistributing routing information via the BGP protocol. This includes: • maintaining the BGP peering connections • applying any defined BGP routing policy	Same as VPN Mgr.	Same as VPN Mgr.	Same as VPN Mgr.	Same as VPN Mgr.
Open Shortest Path First (OSPF)	The OSPF task is created by VPN Manager for each context that has enabled the OSPF routing protocol (router ospf config-context CLI command). The OSPF task is responsible for learning and redistributing routing information via the OSPF protocol. This includes: • maintaining the OSPF neighboring relationship • LSA database maintenance • SPF calculations • applying any defined OSPF routing policy	Same as VPN Mgr.	Same as VPN Mgr.	Same as VPN Mgr.	Same as VPN Mgr.
Open Shortest Path First (OSPFv3)	The OSPFv3 task is created by VPN Manager for each context that has enabled the OSPF routing protocol (router ospfv3 config-context CLI command) The OSPFv3 task is responsible for learning and redistributing routing information via the OSPFv3 protocol. This includes: • maintaining the OSPFv3 neighboring relationship • LSA database maintenance • OSPFv3 SPF calculations • applying any defined OSPFv3 routing policy	Same as VPN Mgr.	Same as VPN Mgr.	Same as VPN Mgr.	Same as VPN Mgr.
Routing Information Protocol (RIP)	The RIP task is created by VPN Manager for each context that has enabled the RIP routing protocol (router rip config-context CLI command) The RIP task is responsible for learning and redistributing routing information via the RIP protocol. This includes: • maintaining the RIP database • sending periodic RIP update messages • applying any defined RIP routing policy	Same as VPN Mgr.	Same as VPN Mgr.	Same as VPN Mgr.	Same as VPN Mgr.
ZEBOSTM OSPF Message	The Zebos task is created by VPN Manager for each context. It is responsible for maintaining the routing table for the context. This includes: • maintaining the routing table (RIB and FIB) • static routing • interfacing to the kernel for routing & interface updates • redistributing routing information to dynamic routing protocols • calculating nexthop reachability	Same as VPN Mgr.	Same as VPN Mgr.	Same as VPN Mgr.	Same as VPN Mgr.

‌

ASR 5x00 Network Processing Unit (NPU) Subsystem

Task	Description	Card	CPU
NPU Controller (NPUCTRL)	Created at system start-up, the NPU Controller performs the following functions: • Monitors the state of NPU Managers in the system. • Registers to receive notifications when NPU Manager crashes. • Controls recovery operation. • Provides a centralized location for CLI commands related to NPU Manager state. Only one NPU Controller operates in the system at any time.	Active SMC	0
NPU Manager (NPUMGR)	The NPU Manager task is created for every PSC installed and started and it performs the following functions: • Provides port configuration services to the CSP task. • Provides interface binding and forwarding services to the VPN Manager. • Provides flow insertion and removal services to Session Manager and AAA Manager tasks. • Provides recovery services to the NPU Controller.	SMCs and packet processing cards	0

‌

ASR 5x00 Session Subsystem

Task	Description	Card		CPU
		w/o SR	w/ SR	w/o SR	w/ SR
Session Controller (SESSCTRL)	Created at system start-up, the Session Controller task performs the following functions: • Acts as the primary point of contact for the Session Subsystem. Since it is aware of the other subsystems running within the system, the Session Controller acts as a proxy for the other components, or tasks, that make up the subsystem. • Starting, configuring, and coordinating the efforts of the Session Processing Subsystem sub-managers. • Works with Resource Manager to start new Session Managers when all existing Session Managers exceed their capacity. • Receives context information from VPN Managers. • Distributes IP interface address information to other Session Processing Subsystem sub-managers. • Manages Enhanced Charging Service, Content Filtering and URL Blacklisting services. Only one Session Controller operating in the system at any time.	Active SMC	Active SMC	0	0
Session Manager (SESSMGR)	Created by the Session Controller, the Session Manager performs the following functions: • Provides a subscriber processing system that supports multiple session types. • Multiple Session Managers can run on a single CPU and/or can be distributed throughout any CPU present in the system. • A single Session Manager can service sessions from multiple A11 Managers, and from multiple contexts. • Protocol processing for A10/A11, GRE, R3, R4, R6, GTPU/GTPC, PPP, and Mobile IP • Manages Enhanced Charging Service, Content Filtering and URL Blacklisting services. Session Managers are paired with AAA Managers.	All packet processing cards	All packet processing cards except the first	0	0 on all packet processing cards except the first
A11 Manager (A11MGR)	Created by the Session Controller for each context in which a PDSN service is configured, the A11 Manager task performs the following functions: • Receives the R-P sessions from the PCF and distributes them to different Session Manager tasks for load balancing. • Maintains a list of current Session Manager tasks to aid in system recovery. The A11 Manager task is also known as the Signaling De-multiplexing task (SDT). NOTE: For ASR 5000s with session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packet processing card.	Active packet processing cards	First packet processing card	0	Any (see NOTE)
Access Link Control Application Part Manager (ALCAPMgr)	The ALCAP Mgr tasks starts when an ALCAP service configuration is detected. There can be multiple instances of this task for load sharing. All ALCAP Managers will have all the Active ALCAP Services configured in HNB-GW service and will be identical in configuration and capabilities. • It runs the ALCAP protocol stack and handles the IuCS-over-ATM associations. • Maintains AAL2 node entity databases. • Provides nodal functions for IuCS-over-ATM interface on ALCAP protocol. NOTE: For ASR 5000s with session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packet processing card. The HNBMGRs should not be started on a packet processing card which has the HNB DEMUX MGR started.	Active packet processing card	Active packet processing card (see NOTE)	0	Any (see NOTE)
ASN Gateway Manager (ASNGWMGR)	Created by the Session Controller, the ASN Gateway Manager performs the following functions: • Provides a subscriber processing system that supports multiple session types. • Multiple ASNGW Managers can run on a single CPU and/or can be distributed throughout any CPU present in the system. • A single ASNGW Manager can service sessions from multiple ASN PC Managers and multiple contexts. • Protocol processing for R3, R4, R6, GRE tunneling, and Mobile IP	Active packet processing cards		0
ASN PC Manager (ASNPCMGR)	Created by the Session Controller, the ASN Paging Controller and Location Registry Manager performs the following functions: • Provides a subscriber processing system that supports multiple paging controller and location update session types. • Multiple ASNPC Managers can run on a single CPU and/or can be distributed throughout any CPU present in the system. • A single ASN GW Manager can service sessions from multiple contexts. • Protocol processing for R3, R4, R6, GRE tunneling, and Mobile IP	Active packet processing cards		0
Authorization, Authentication, and Accounting (AAA) Manager (AAAMGR)	AAA Managers are paired with Session Managers (except the one running on the SMC) and perform the following functions: • Performs all AAA protocol operations and functions for subscribers and administrative users within the system. • Acts as a AAA client to AAA servers. • Manages GTP Prime (GTPP) messaging with charging gateway functions (CGFs). • Multiple AAA Managers can run on a single CPU and/or can be distributed throughout any CPU present in the system. • AAA operations for the CLI are done through a AAA Manager running on the active SMC.	Active packet processing cards	All packet processing cards (except first)	All except 0	All
		Active SMC (CLI only)	Active SMC (CLI only)	0	0
Charging Detail Record Module (CDRMOD)	Responsible for receiving EDR/UDR records from different ACSMGR instances in the system. Responsible for writing the received EDR/UDR records in files using the configured file naming conventions.	First packet processing card	First packet processing card	0	0
Diameter GMB Application Manager (DGMBMGR)	DGMBMGR is created specifically for providing MBMS feature support for GGSN. It is instantiated when an MBMS policy CLI is configured in the GGSN Service configuration mode. DGMBMGR maintains the MBMS UE and bearer contexts. It handles the GMB interface over a Diameter connection to a BMSC Server for MBMS bearer sessions. DGMBMGR recovers by polling all SMGRs for MBMS session states and recreating the MBMS UE and MBMS bearer context information.	Active packet processing cards		0
Diameter Proxy (DIAMPROXY)	Diameter proxy is created by DIACTRL (which runs as part of VPNCTRIL) and the number of DIAMPROXY tasks spawned is based on the configuration to use “multiple” or “single” proxies. In instances that a single proxy is configured, only one DIAMPROXY task is spawned for the entire chassis and runs on demux packet processing cards. When multiple proxies are configured, one DIAMPROXY task is run per packet processing card. It performs the following functions: • Maintains Diameter base connections to all peers configured in the system. • Informs applications about any change in the connection status. • Acts as a pass-through to the messages from application to the Diameter server. • Just acts as a forwarding agent (does not maintain any queues) A single Diameter proxy is used to service multiple Diameter applications.	Active packet processing cards (see description)	Active packet processing cards (see description)	All (see description)	All (see description)
eGTP Egress Manager	Created by Session Controller for each context in which an egtp-service of interface type sgw-egress or MME is configured. The egtpinmgr performs the following functions: • Handles certain EGTP messages from SGW, PGW. • Maintains list of current EGTP sessions. • Maintains list of current Session Manager tasks which aids in session recovery. • Handles GTP Echo messaging. NOTE: For ASR 5x00s with session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packet processing card.	Packet processing card	First packet processing card	All	Any (see NOTE)
eGTP Ingress Manager	Created by Session Controller for each context in which an egtp-service of interface type sgw-ingress or pgw-ingress is configured. The egtpinmgr performs the following functions: • Receives EGTP sessions from MME/S4 SGSN/SGW and distributes them to different Session Manager tasks for load balancing. • Maintains list of current EGTP sessions. • Maintains list of current Session Manager tasks which aids in session recovery. • Handles GTP Echo messaging. NOTE: For ASR 5x00s with session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packet processing card.	Packet processing card	First packet processing card	All	Any (see NOTE)
Foreign Agent (FA) Manager (FAMGR)	Created by the Session Controller for each context in which an FA service is configured, the FA Manager performs the following functions: • Maintains a list of the FA-services available within the context and performs load-balancing for them • Performs load-balancing by routing incoming MIP calls between the FA Managers NOTE: For ASR 5000s with session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active PSC.	Active packet processing cards	First packet processing card	0	Any (see NOTE)
GPRS Tunneling Protocol Control (GTPC) Message Manager (GTPCMGR)	Created by the Session Controller for each context in which a GGSN service is configured, the GTPC Manager task performs the following functions: • Receives the GTP sessions from the SGSN and distributes them to different Session Manager tasks for load balancing. • Maintains a list of current Session Manager tasks to aid in system recovery. • Verifies validity of GTPC messages. • Maintains a list of current GTPC sessions. • Handles GTPC Echo messaging to/from SGSN.	Active packet processing cards		0
GTP-U Manager (GTPUMGR)	Created by the Session Controller for each context in which a GTPU service is configured, the GTPU Manager performs the following functions: • Maintains a list of the GTPU-services available within the context and performs load-balancing (of only Error-Ind) for them. • Support for GTPU Echo handling • Path Failure detection on no response for GTPU echo • Error-Ind reception and demuxing it to a particular Session Manager. • Default GTPU listener. GTPUMGR will process GTPU packets with invalid TEID. Above features are supported for both GTPUv0 and GTPUv1. NOTE: For ASR 5x00s with session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the First active PSC.	Active packet processing cards	First packet processing card	0	Any (see NOTE)
HNB Demux Manager (HNBDemux)	The HNB Demux Manager is started as part of HNB-GW service creation procedure. There will be only one HNBDEMUX MGR in the chassis. • Distributes incoming Iuh connections to HNB Mgrs in the system. • Aware of all the active HNB-GW services in the system. NOTE: For ASR 5000s with session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packet processing card, but should not be created on the same packet processing card that has HNB Manager.	Packet processing card	Packet processing card (see NOTE)	0	Any (see NOTE)
HNB Manager (HNBMgr)	The HNB Mgr tasks starts when an HNB-GW service configuration is detected. There can be multiple instances of this task for load sharing. All HNB Managers will have all the Active HNB-GW Services configured and will be identical in configuration and capabilities. • It runs the SCTP protocol stack. • Handles the SCTP associations. • Maintains Home-NodeB databases • Provides nodal functions for Iuh interface on SCTP protocol. NOTE: For ASR 5000s with session recovery (SR) enabled, this manager is usually established on one of the CPUs on the first active packet processing card. The HNBMGRs should not be started on a packet processing card which has the HNB DEMUX MGR started.	Active packet processing card	Active packet processing card (see NOTE)	0	Any (see NOTE)
Home Agent (HA) Manager (HAMGR)	Created by the Session Controller for each context in which an HA service is configured, the HA Manager performs the following functions: • Receives Mobile IP sessions from the Foreign Agents (FAs) and distributes them to different Session Manager tasks • Maintains a list of current Session Manager tasks that aids in system recovery • Functions as the DemuxMgr – handles all the PMIP signaling packets. • HAMgr also functions as the Demuxmgr for MIPv6/MIPv4 HA. NOTE: For ASR 5000s with session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packet processing card.	Active packet processing cards	First packet processing card	0	Any (see NOTE)
IMSI Manager for MME (IMSIMgr)	The IMSI Mgr tasks starts when an MME service configuration is detected. There will be only one instance of this task. IMSI Manager performs the following functions: • Signaling De-multiplexer: Selects which SessMgr to use for new subscriber sessions. • IMSI-to-SessMgr resolution: Maintains and reports MME-related demux statistics on events like Attach by IMSI, Attach by GUTI, etc. IMSIMgr can interact with following different tasks in the system: • Session Controller • MME Manager • Session Manager NOTE: For ASR 5000s with session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packet processing card. The IMSIMgr will not start on a packet processing card in which SessMgrs are started.	Active packet processing card	Active packet processing card (see NOTE)	0	Any (see NOTE)
International Mobile Subscriber Identity Manager for SGSN (IMSIMgr)	Started by the Session Controller, the IMSIMgr performs the following functions • Selects SessMgr, when not done by LinkMgr or SGTPCMgr, for calls sessions based on IMSI/P-TMSI. • Load-balances across SessMgrs to select one for assigning subscriber sessions to. • Maintains records for all subscribers on the system. • Maintains mapping between the IMSI/P-TMSI and SessMgrs. NOTE: For ASR 5000s with session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active deumux packet processing card. The IMSIMgr will not start on a packet processing card in which SessMgrs are already started.	Active packet processing card	Active packet processing card (see NOTE)	0	Any (see NOTE)
IP Services Gateway Manager (IPSGMGR)	Created by the Session Controller, the IPSG Manager performs the following functions: • In Server mode, acts as a RADIUS server, and supports Proxy functionality • In Snoop mode supports snooping RADIUS Accounting messages. • Load balances requests among different SessMgrs. • Activates and deactivates sessions.	Active packet processing cards	—	0	—
Layer 2 Tunneling Protocol Manager (L2TPMGR)	Created by the Session Controller for each context in which a LAC or LNS service is configured, (additional Managers created as needed depending on loading) the L2TP Manager task performs the following functions: • Responsible for all aspects of L2TP processing • Maintain protocol state machines for all L2TP sessions and tunnels • Trigger IPSec encryption for new L2TP tunnels as needed • Work with Session Managers to gracefully bring down tunnels NOTE: For ASR 5x00s with session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packet processing card.	Active packet processing cards	First packet processing card	0	Any (see NOTE)
L2TP Demultiplexor Task (L2TPDEMUX)	Created by the Session Controller when an LNS service is created, only one L2TPDemux task is invoked for the entire system. This task performs the following functions: • De-multiplexes and forwards new incoming tunnel create requests to L2TPMgrs. • Maintains information about current active tunnels in all L2TPMgrs. • Load balances requests among L2TPMgrs. NOTE: For ASR 5x00s with session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packet processing card.	Active packet processing cards	First packet processing card.	0	Any (see NOTE)
Mobile Access Gateway Manager	Created by the Session Controller when the first MAG service is created in a context. This task performs the following functions: • Sends and receives PMIP control messages (PBU/PBA) • Adds an NPU flow to receive MIPv6 PBA packets. This flow is identical to the flow used in the HAMgr • Maintains the Binding Update List used to keep track of the mobile node’s bindings: • MN-ID • APN • Home Network Prefix and prefix length • IPv6 LMA address • IPv4 Home Address • Originates PBU-based on trigger received from the Session Manager during error conditions. • Receives PBA and forwards it to Session Manager. • Debugging facility – “magmgr” and “mobile-ipv6”	Packet processing card		Same as VPN Mgr.
Mobility Management Entity Demux Manager (MMEDemux)	The MME Demux Manager is started as part of MME service creation procedure. There will be only one MME DEMUX MGR in the chassis. • Distributes incoming S1-MME SCTP connections to MME Mgrs in the system. • Aware of all the active MME services in the system. NOTE: For ASR 5x00s with session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the First active packet processing card but should not be created on the same packet processing card that has MME Manager.	Packet processing card	Packet processing card (see NOTE)	0	Any (see NOTE)
Mobility Management Entity Manager (MMEMgr)	The MME Mgr tasks starts when an MME service configuration is detected. There can be multiple instances of this task for load sharing. All MME Managers will have all the Active MME Services configured and will be identical in configuration and capabilities. • Runs the SCTP protocol stack. • Handles the SCTP associations. • Maintains TA List. • Manage eNodeB databases. • Provides nodal functions for S1-MME protocol. NOTE: For ASR 5x00s with session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packet processing card. The MMEMGRs should not be started on a packet processing card which has the MME DEMUX MGR started.	Active packet processing card	Active Active packet processing card (see NOTE)	0	Any (see NOTE)
PCC Bindmux Manager (PCC Demux)	The Bindmux Manager is started as part of PCC service creation procedure. There will be only one BindMux MGR in the chassis. The BindMux function handles multiplexing of the sessions across the available PCCMgrs along with the session binding functions. The capabilities includes: • Monitors load on PCCMgrs • Distributes incoming IP-CAN connections across PCC Mgrs in the system • Perform session binding; binds IP-CAN/Gateway session with the AF-Session • Ensure all messaging for an IMSI across various interfaces is directed towards the selected PCCMgr • Aware of all the active PCC services in the system. NOTE: For ASR 5x00s with session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active packet processing card but should not be created on the same packet processing card that has PCC Manager.	Active packet processing card	Active packet processing card (see NOTE)	0	Any (see NOTE)
PCC Manager (PCCMgr)	The PCC Manager is part of the SessMgr process. All PCC Managers will have all the Active PCC Policy Services configured and will be identical in configuration and capabilities. The PCC Manager function manages all the sessions and forms the main block of IPCF functionality which is making authorization decisions. This is the rules engine that acts on the user defined policy profiles; implements rules to generate the policy and charging decision applicable to a subscriber's usage towards an application service. Along with the PCC processing logic, the PCC-Mgr co-hosts the Gx-API and Rx-API modules. It includes the following capabilities: • Runs the Gx/Gxa protocol stack. • Handles the IP-CAN associations. • Provides nodal functions for Gx/Gxa/Rx interface with PCEF/BBERF/AF. NOTE: For ASR 5x00s with session recovery (SR) enabled, this manager is usually established on one of the CPUs on the first active packet processing card. The PCCMGRs should not be started on a packet processing card which has the PCC BINDMUX MGR started.	Active packet processing card	Active packet processing card (see NOTE)	0	Any (see NOTE)
SPR Manager (SPRMgr)	The SPR Manager is part of AAAMgr process and manages the transactions towards an external SSC/SPR node over Sp interface. The Sp interface is based on Sh protocol interface. The SPRMgr abstracts the Sp interactions required for the PCC functions. For more information, refer AAAMgr portion of this table.	Active packet processing card	Active packet processing card (see NOTE)	0	Any (see NOTE)
SGSN GPRS Tunneling Protocol Control message Manager (SGTPCMgr)	Created by the Session Controller for each VPN context in which an SGSN service is configured, the SGTPC Manager task performs the following functions: • Terminates Gn/Gp and GTP-U interfaces from peer GGSNs and SGSNs for SGSN Services. • Terminates GTP-U interfaces from RNCs for IuPS Services. • Controls standard ports for GTP-C and GTP-U. • Processes and distributes GTP-traffic received from peers on these ports. • Performs all node level procedures associated with Gn/Gp interface. NOTE: For ASR 5x00s with session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active demux packet processing card. The IMSIMgr will not start on a packet processing card in which SessMgrs are already started.	Active packet processing card	Active Demux packet processing card (see NOTE)	0	Any (see NOTE)
SGSN Master Manager (MMgr)	MMgr is created upon provisioning of SS7RDs/SCCP-NWs/etc., The Session Controller provides the initial system configuration which includes a detailed description of each distributed protocol layer, its resources sets, and a list of its service user protocol layers and service provider protocol layers. The MMgr task runs in duplex mode (active/standby) to perform the following functions: • Single instanced • Handles nodal SS7, Iu, and Gb functionality. • Implements master LinkMgr functionality for SS7 route status aggregation. • Implements master LinkMgr functionality for RNC and BSC status aggregation. NOTE: For ASR 5000s with session recovery (SR) enabled, this demux manager is usually established on one of the CPUs on the first active demux packet processing card. The IMSIMgr will not start on a packet processing card in which SessMgrs are already started.	Active packet processing card	Active Demux packet processing card (see NOTE)	0	Any (see NOTE)
SS7 Link Manager (LinkMgr)	Created by the Session Controller when the first SS7RD (routing domain) is activated, the LinkMgr performs the following functions: • Multi-instanced for redundancy and scaling purposes. • Provides SS7 and Gb connectivity to the platform. • Routes per subscriber signalling across the SS7 (including Iu) and Gb interfaces to the SessMgr.	Any Active packet processing card not running an MMgr	Any Active non- demux packet processing card
Standard Routing Database (SRDB)	Eight SRDBs are created by the Session Controller when Content Filtering in the Enhanced Charging Service is enabled. A minimum of two packet processing cards are required to initiate these eight tasks. SRDB performs the following functions: • The SRDB task receives the static database from the session controller. Each SRDB task loads two database volumes (one primary and one secondary). The SRDB task also stores the static DB. • The SRDB task rates the URL. It returns the proper category of the URL depending on the DB volumes and CSI (category set Index) stored on it. • The SRDB tasks perform peer loading in case its peer fails. If both the SRDB task and its peer fail, the session controller performs the loading.	Peer SRDBs evenly distributed across packet processing cards

‌

ASR 5x00 Platform Processes

Task	Description	Card		CPU
		w/o SR	w/ SR	w/o SR	w/ SR
Card-Slot-Port Controller (CSPCTRL)	Manages physical chassis components.	SMC	SMC	0	0
Messenger Daemon (MSGD)	Implements the Name Service and related functions for the internal message passing system.	All	All	All	All
Name Service Controller (NSCONTROL)	As part of the Messenger process, NSControl provides a reliable channel for tasks to send control messages to the Messenger Daemon.	All	All	All	All
Daughter Card Controller (DCARDCTRL)	The daughter card controller spawns daughter card managers during system initialization and monitors daughter card managers during system steady state execution. The daughter card controller spawns daughter card managers in case a daughter card manager task fails.	Active SMC	Active SMC	0	0
Daughter Card Manager (DCARDMGR)	The daughter card manager is responsible for managing IPSec Security Associations for AH- and ESP-based sessions. The daughter card manager is also responsible for interfacing to the on-board hardware accelerated cryptographic chip which executes cryptographic algorithms associated with the given IPSec Security Associations.	All packet processing cards	All packet processing cards	0	0
Distributed Host Manager (DHMGR)	Started automatically on each CPU by SITPARENT. Coordinates establishment of locally terminated TCP, SCTP, and UDP connections on behalf of multi-instanced tasks such as Diameter endpoints among SESSMGR tasks.	All	All	All	All
Driver Controller (DRVCTRL)	The driver controller centralizes accesses to many of the system device drivers. It also performs temperature and voltage monitoring.	SMCs	SMCs	0	0
Hard Drive Controller (HDCTRL)	The hard drive controller controls/manages the drive array spanning the SMCs.	SMCs	SMCs	0	0
IPSec Controller (IPSECCTRL)	The IPSec controller is started by SIT on system startup regardless of configuration and performs the following functions: • Starts IPSECMGR tasks based on configuration and maintains its list for task recovery. • Receives and maintains user configuration for IPSec. • Manages the configured IPSec crypto maps and its assignment to IPSECMGRs. • Interfaces with the VPNMGR task for required IPSec configuration parameters such as IP Access-lists, IP pools, interface addresses, and interface state notifications.	Active SMC	Active SMC	0	0
IPSec Manager (IPSECMGR)	Created by the Session Controller, the IPSECMGR establishes and manages secure IKEv1, IKEv2 and IPSec data tunnels.	Packet processing card	Packet processing card	All	All
Recovery Control Task (RCT)	Monitors tasks/managers/facilities across the system and performs recovery in the event of a failure.	SMCs	SMCs	0	0
Shared Configuration Task (SCT)	Performs the redundant storage of configuration information and other state information in an in-memory database.	SMCs	SMCs	0	0
Switch Fabric Task (SFT)	The switch fabric task monitors the switch fabric and the gigabit Ethernet control plane.	Packet processing cards	Packet processing cards	0	0
Utilities Configuration Manager (UCM)	DHCPD, DNS, FTPD, INETD, NTPD, PING, RLOGIN, SFTPD, SFTP-SERVER, SNMPD, SSH, SSHD, TELNET, TELNETD, TFTPD, TRACEROUTE	Active SMC	Active SMC	0	0

‌

ASR 5x00 Management Processes

Task	Description	Card		CPU
		w/o SR	w/ SR	w/o SR	w/ SR
Bulk Statistic Manager (BULKSTAT)	Performs a periodic statistic polling/gathering function (bulk statistics) and handles the transfer of this data to external management systems.	Active SMC	Active SMC	0	0
Event Log Daemon (EVLOGD)	Handles event logging functions including the interface to external syslogd servers and the internal event logs.	Active SMC	Active SMC	0	0
ORB Service (ORBS)	The ORBS task is also known as the ORB Element Manager (ORBEM). Application Servers (EMS) request ORBS to perform Element Management Functions on the system using secure IIOP. ORBS then interacts with concerned Controller Tasks to execute the function. The response/errors from the execution is interpreted, formulated into EMF response, and handed over to Application Server (EMS).	Active SMC	Active SMC	0	0
ORB Notification Service (ORBNS)	The ORBNS task performs the following functions: • There are different types of event that can continually occur within Boxer. • The Application Servers (EMS) may be notified of occurrences of these events. • Such Application Servers (EMS) may register with ORBS (ORBEM) subscribing to the types of events they are interested in. • As the events occur, the concerned Controller Task notifies ORBS (ORBEM), which then notifies the subscribing Application Servers (EMS).	Active SMC	Active SMC	0	0
Session Trace Collection Task (SESSTRC)	The session trace task implements the standards-based session trace functionality. The session trace task manages both CLI and signaling-based subscriber traces. It collects messages to be traced and generates trace files as needed. It uploads trace files to the Trace Collection Entity as needed.	Active SMC	Active SMC	0	0
Simple Network Management Protocol (SNMP)	Handles inboard SNMP operations if configured, and sends SNMP notifications (traps) if enabled.	Active SMC	Active SMC	0	0
Threshold Server (THRESHOLD)	Handles monitoring of threshold crossing alerts, if configured. Polls the needed statistics/variables, maintains state, and generates log messages/SNMP notification of threshold crossings.	Active SMC	Active SMC	0	0

‌

 

 

Appendix C
Access Control Lists

 

 

This appendix describes system support for access control lists and explains how they are configured. The product administration guides provide examples and procedures for configuration of basic services on the system. You should select the configuration example that best meets your service model before using the procedures in this appendix.

Important: You do not require a license to configure ACLs. However, the number of ACLs configured may impact performance significantly.

This appendix contains the following sections:

•	Understanding ACLs

•	Configuring ACLs on the System

•	Applying IP ACLs

Important: Not all commands and keywords/variables may be available. Availability depends on the platform type.

Overview

IP access lists, commonly known as access control lists (ACLs), control the flow of packets into and out of the system. They are configured on a per-context basis and consist of “rules” (ACL rules) or filters that control the action taken on packets that match the filter criteria. Once configured, an ACL can be applied to any of the following:

•	An individual interface

•	All traffic facilitated by a context (known as a policy ACL)

•	An individual subscriber

•	All subscriber sessions facilitated by a specific context

 

Understanding ACLs

This section discusses the two main aspects to ACLs on the system:

•

Rule(s)

•	Rule Order

Important: Refer to the ACL Configuration Mode Commands chapter of the Command Line Interface Reference for the full command syntax.

Rule(s)

A single ACL consists of one or more ACL rules. Each rule is a filter configured to take a specific action when packets matching specific criteria. Up to 128-rules can be configured per ACL.

Important: Configured ACLs consisting of no rules imply a “deny any” rule. The deny action and any criteria are discussed later in this section. This is the default behavior for an empty ACL.

Each rule specifies the action to take when a packet matches the specifies criteria. This section discusses the rule actions and criteria supported by the system.

Actions

ACLs specify that one of the following actions can be taken on a packet that matches the specified criteria:

•	Permit: The packet is accepted and processed.

•	Deny: The packet is rejected.

•	Redirect: The packet is forwarded to the specified next-hop address through a specific system interface or to the specified context for processing.

Important: Redirect rules are ignored for ACLs applied to specific subscribers or all subscribers facilitated by a specific context, or APN for UMTS subscribers.

Criteria

Each ACL consists of one or more rules specifying the criteria that packets will be compared against.

The following criteria are supported:

•	Any: Filters all packets

•	Host: Filters packets based on the source host IP address

•	ICMP: Filters Internet Control Message Protocol (ICMP) packets

•	IP: Filters Internet Protocol (IP) packets

•	Source IP Address: Filter packets based on one or more source IP addresses

•	TCP: Filters Transport Control Protocol (TCP) packets

•	UDP: Filters User Datagram Protocol (UDP) packets

Each of the above criteria are described in detail in the sections that follow.

Important: The following sections contain basic ACL rule syntax information. Refer to the ACL Configuration Mode Commands chapter of the Command Line Interface Reference for the full command syntax.

 

•	Any: The rule applies to all packets.

•	Host: The rule applies to a specific host as determined by its IP address.

•	ICMP: The rule applies to specific Internet Control Message Protocol (ICMP) packets, Types, or Codes. ICMP type and code definitions can be found at www.iana.org (RFC 3232).

•	IP: The rule applies to specific Internet Protocol (IP) packets or fragments.

•	IP Packet Size Identification Algorithm: The rule applies to specific Internet Protocol (IP) packets identification for fragmentation during forwarding.

This configuration is related to the “IP Identification field” assignment algorithm used by the system, when subscriber packets are being encapsulated (such as Mobile IP and other tunneling encapsulation). Within the system, subscriber packet encapsulation is done in a distributed way and a 16-bit IP identification space is divided and distributed to each entity which does the encapsulation, so that unique IP identification value can be assigned for IP headers during encapsulation.

Since this distributed IP Identification space is small, a non-zero unique identification will be assigned only for those packets which may potentially be fragmented during forwarding (since the IP identification field is only used for reassembly of the fragmented packet). The total size of the IP packet is used to determine the possibility of that packet getting fragmented.

•	Source IP Address: The rule applies to specific packets originating from a specific source address or a group of source addresses.

•	TCP: The rule applies to any Transport Control Protocol (TCP) traffic and could be filtered on any combination of source/destination IP addresses, a specific port number, or a group of port numbers. TCP port numbers definitions can be found at www.iana.org

•	UDP: The rule applies to any User Datagram Protocol (UDP) traffic and could be filtered on any combination of source/destination IP addresses, a specific port number, or a group of port numbers. UDP port numbers definitions can be found at www.iana.org.

Rule Order

A single ACL can consist of multiple rules. Each packet is compared against each of the ACL rules, in the order in which they were entered, until a match is found. Once a match is identified, all subsequent rules are ignored.

Additional rules can be added to an existing ACL and properly ordered using either of the following options:

•

Before

•

After

Using these placement options requires the specification of an existing rule in the ACL and the configuration of the new rule as demonstrated by the following flow:

[ before | after ] { <existing_rule> }

Configuring ACLs on the System

This section describes how to configure ACLs.

Important: This section provides the minimum instruction set for configuring access control list on the system. For more information on commands that configure additional parameters and options, refer to the ACL Configuration Mode Commands chapter in the Command Line Interface Reference.

To configure the system to provide an access control list facility to subscribers:

Step 1

Create the access control list by applying the example configuration in the Creating ACLs section.

Step 2

Specify the rules and criteria for action in ACL list by applying the example configuration in the Configuring Action and Criteria for Subscriber Traffic section.

Step 3

Optional. The system provides an “undefined” ACL that acts as a default filter for all packets into the context. The default action is to “permit all”. Modify the default configuration for “unidentified” ACLs for by applying the example configuration in the Configuring an Undefined ACL section.

Step 4

Verify your ACL configuration by following the steps in the Verifying the ACL Configuration section.

Step 5

Save your configuration as described in the Verifying and Saving Your Configuration chapter in this guide.

Creating ACLs

To create an ACL, enter the following command sequence from the Exec mode of the system CLI:

configure

  context <acl_ctxt_name> [ -noconfirm ]

     ip access-list <acl_list_name>

        end

Notes:

•	The maximum number of ACLs that can be configured per context is limited by the amount of available memory in the VPN Manager software task. Typically, the maximum is less than 200.

Configuring Action and Criteria for Subscriber Traffic

To create rules to deny/permit the subscriber traffic and apply the rules after or before action, enter the following command sequence from the Exec mode of the system CLI:

configure

  context <acl_ctxt_name> [ -noconfirm ]

     ip access-list <acl_list_name>

        deny { <ip_address> | any | host | icmp | ip | log | tcp | udp }

        permit { <ip_address> | any | host | icmp | ip | log | tcp | udp }

        after { deny | permit | readdress | redirect }

        before { deny | permit | readdress | redirect }

        end

Notes:

Caution: The system does not apply a “deny any” rule, unless it is specified in the ACL. This behavior can be changed by adding a “deny any” rule at the end of the ACL.

 

•	The maximum number of rules that can be configured per ACL varies depending on how the ACL is to be used. For more information, refer to the Engineering Rules appendix in this guide.

•	Use the information provided in the Actions and Criteria sections of this appendix to configure the rules that comprise the ACL. For more information, refer to the ACL Configuration Mode Commands chapter in the Command Line Interface Reference.

Configuring an “Undefined” ACL

As discussed previously in this chapter the system uses an “undefined” ACL mechanism for filtering the packet(s) in the event that an ACL that has been applied is not present. This scenario is likely the result of a mis-configuration such as the ACL name being mis-typed during the configuration process.

For these scenarios, the system provides an “undefined” ACL that acts as a default filter for all packets into the context. The default action is to “permit all”.

To modify the default behavior for unidentified ACLs, use the following configuration:

configure

  context <acl_ctxt_name> [ -noconfirm ]

     access-list undefined { deny-all | permit-all }

     end

Notes:

•	Context name is the name of the context containing the “undefined” ACL to be modified. For more information, refer to the Context Configuration Mode Commands chapter in the Command Line Interface Reference.

Verifying the ACL Configuration

To verify the ACL configuration:

Step 1

In the Exec Mode, enter the show ip access-list command.

The following is a sample output of this command. In this example, an ACL named acl_1 was configured.

ip access list acl_1

  deny host 1.2.3.4

  deny ip any host 1.2.3.4

  permit any 1.2.4.4

1 ip access-lists are configured.

 

Applying IP ACLs

Once an ACL is configured, it must be applied to take effect.

Important: All ACLs should be configured and verified according to the instructions in the Configuring ACLs on the System section of this appendix prior to beginning these procedures. The procedures described below also assume that the subscribers have been previously configured.

As discussed earlier, you can apply an ACL to any of the following:

•	Applying an ACL to an Individual Interface

•	Applying an ACL to All Traffic Within a Context (known as a policy ACL)

•	Applying an ACL to an Individual Subscriber

•	Applying a Single ACL to Multiple Subscribers

•	Applying a Single ACL to Multiple Subscribers via APNs (for 3GPP subscribers only)

Important: ACLs must be configured in the same context in which the subscribers and/or interfaces to which they are to be applied. Similarly, ACLs to be applied to a context must be configured in that context.

If ACLs are applied at multiple levels within a single context (such as an ACL is applied to an interface within the context and another ACL is applied to the entire context), they will be processed as shown in the following figure and table.

ACL Processing Order

ACL Processing Order Descriptions

Packet coming from the mobile node to the packet data network (left to right)
Order	Description
1	An inbound ACL configured for the receiving interface in the Source Context is applied to the tunneled data (such as the outer IP header). The packet is then forwarded to the Destination Context.
2	An inbound ACL configured for the subscriber (either the specific subscriber or for any subscriber facilitated by the context) is applied.
3	A context ACL (policy ACL) configured in the Destination Context is applied prior to forwarding.
4	An outbound ACL configured on the interface in the Destination Context through which the packet is being forwarded is applied.
Packet coming from the packet data network to the mobile node (right to left)
Order	Description
1	An inbound ACL configured for the receiving interface configured in the Destination Context is applied.
2	An outbound ACL configured for the subscriber (either the specific subscriber or for any subscriber facilitated by the context) is applied. The packet is then forwarded to the Source Context.
3	A context ACL (policy ACL) configured in the Source Context is applied prior to forwarding.
4	An outbound ACL configured on the interface in the Source Context through which the packet is being forwarded is applied to the tunneled data (i.e. the outer IP header).

‌

In the event that an IP ACL is applied that has not been configured (for example, the name of the applied ACL was configured incorrectly), the system uses an “undefined” ACL mechanism for filtering the packet(s).

This section provides information and instructions for applying ACLs and for configuring an “undefined” ACL.

Applying an ACL to an Individual Interface

This section provides information and instructions for applying one or more ACLs to an individual interface configured on the system.

Important: This section provides the minimum instruction set for applying the ACL list to an interface on the system. For more information on commands that configure additional parameters and options, refer to the Ethernet Interface Configuration Mode Commands chapter in the Command Line Interface Reference.

To configure the system to provide ACL facility to subscribers:

Step 1

Apply the configured access control list by applying the example configuration in the Applying ACL to Interface section.

Step 2

Verify that ACL is applied properly on interface by following the steps in the Verifying the ACL Configuration on Interface section.

Step 3

Save your configuration as described in the Verifying and Saving Your Configuration chapter in this guide.

Applying ACL to Interface

To apply the ACL to an interface, use the following configuration:

configure

  context <acl_ctxt_name> [ -noconfirm ]

     interface <interface_name>

        ip access-group <acl_list_name> { in | out } [ <preference> ]

        end

Notes:

•	The context name is the name of the ACL context containing the interface to which the ACL is to be applied.

•	The ACL to be applied must be configured in the context specified by this command.

•	Up to 8 ACLs can be applied to a group provided that the number of rules configured within the ACL(s) does not exceed the 128-rule limit for the interface.

Verifying the ACL Configuration on Interface

This section describes how to verify the ACL configuration.

Step 1

In the Exec Mode, enter the following command:

show configuration context context_name

context_name is the name of the context containing the interface to which the ACL(s) was/were applied.

The output of this command displays the configuration of the entire context. Examine the output for the commands pertaining to interface configuration. The commands display the ACL(s) applied using this procedure.

configure

  context context_name

     ip access-list acl_name

        deny host ip_address

        deny ip any host ip_address

        exit

     ip access-group access_group_name

     service-redundancy-protocol

        exit

     interface interface_name

        ip address ip_address/mask

        exit

     subscriber default

        exit

     aaa group default

        exit

     gtpp group default

        end

Applying an ACL to All Traffic Within a Context

This section provides information and instructions for applying one or more ACLs to a context configured within a specific context on the system. The applied ACLs, known as policy ACLs, contain rules that apply to all traffic facilitated by the context.

Important: This section provides the minimum instruction set for applying the ACL list to all traffic within a context. For more information on commands that configure additional parameters and options, refer to the Context Configuration Mode Commands chapter in the Command Line Interface Reference.

To configure the system to provide access control list facility to subscribers:

Step 1

Apply the configured ACL as described in the Applying ACL to Context section.

Step 2

Verify that ACL is applied properly on interface as described in the Verifying the ACL Configuration in a Context section.

Step 3

Save your configuration as described in the Verifying and Saving Your Configuration chapter in this guide.

Applying ACL to Context

To apply the ACLs to a context, use the following configuration:

configure

  context <acl_ctxt_name> [ -noconfirm ]

     ip access-group <acl_list_name> [ in | out ] [ <preference> ]

     end

Notes:

•	The context name is the name of the ACL context containing the interface to which the ACL is to be applied.

•	The context-level ACL are applied only to outgoing packets. The in and out keywords are deprecated and are only present for backward compatibility.

•	The ACL to be applied must be configured in the context specified by this command.

•	Up to 8 ACLs can be applied to a group provided that the number of rules configured within the ACL(s) does not exceed the 128-rule limit for the interface.

Verifying the ACL Configuration in a Context

To verify the ACL configuration:

Step 1

Verify that your ACL lists were applied properly by entering the following command in Exec Mode:

show configuration context context_name

context_name is the name of the context to which the ACL(s) was/were applied.

The output of this command displays the configuration of the entire context. Examine the output for the commands pertaining to interface configuration. The commands display the ACL(s) applied using this procedure.

configure

  context context_name

     ip access-list acl_name

        deny host ip_address

        deny ip any host ip_address

        exit

     ip access-group access_group_name

     service-redundancy-protocol

        exit

     interface interface_name

        ip address ip_address/mask

        exit

     subscriber default

        exit

     aaa group default

        exit

     gtpp group default

        end

Applying an ACL to a RADIUS-based Subscriber

IP ACLs are applied to subscribers via attributes in their profile. The subscriber profile could be configured locally on the system or remotely on a RADIUS server.

To apply an ACL to a RADIUS-based subscriber, use the Filter-Id attribute. Refer to the AAA and GTPP Interface Administration and Reference for more detail on this attribute.

This section provides information and instructions for applying an ACL to an individual subscriber whose profile is configured locally on the system.

Important: This section provides the minimum instruction set for applying the ACL list to all traffic within a context. For more information on commands that configure additional parameters and options, refer to the Subscriber Configuration Mode Commands chapter in the Command Line Interface Reference.

To configure the system to provide access control list facility to subscribers:

Step 1

Apply the configured access control list by applying the example configuration in the Applying ACL to an Individual Subscriber section.

Step 2

Verify that ACL is applied properly on interface by following the steps in the Verifying the ACL Configuration to an Individual Subscriber section.

Step 3

Save your configuration as described in the Verifying and Saving Your Configuration chapter in this guide.

Applying an ACL to an Individual Subscriber

To apply the ACL to an individual subscriber, use the following configuration:

configure

  context <acl_ctxt_name> [ -noconfirm ]

     subscriber name <subs_name>

        ip access-group <acl_list_name> [ in | out ]

        end

Notes:

•	The context name is the name of the ACL context containing the interface to which the ACL is to be applied.

•	If neither the in nor the out keyword is specified, the ACL will be applied to all inbound and outbound packets.

•	The ACL to be applied must be configured in the context specified by this command.

•	Up to 8 ACLs can be applied to a group provided that the number of rules configured within the ACL(s) does not exceed the 128-rule limit for the interface.

Verifying the ACL Configuration to an Individual Subscriber

These instructions are used to verify the ACL configuration.

Step 1

Verify that your ACL lists were applied properly by entering the following command in Exec Mode:

show configuration context context_name

context_name is the name of the context containing the subscriber subs1 to which the ACL(s) was/were applied.

The output of this command displays the configuration of the entire context. Examine the output for the commands pertaining to interface configuration. The commands display the ACL(s) applied using this procedure.

configure

  context context_name

     ip access-list acl_name

        deny host ip_address

        deny ip any host ip_address

        exit

     ip access-group access_group_name

     service-redundancy-protocol

        exit

     interface interface

        ip address ip_address/mask

        exit

     subscriber default

        exit

     subscriber name subscriber_name

        ip access-group access_group_name in

        ip access-group access_group_name out

        exit

     aaa group default

        exit

     gtpp group default

        exit

     content-filtering server-group cfsg_name

        response-timeout response_timeout

        connection retry-timeout retry_timeout

        end

Applying a Single ACL to Multiple Subscribers

As mentioned in the previous section, IP ACLs are applied to subscribers via attributes in their profile. The subscriber profile could be configured locally on the system or remotely on a RADIUS server.

The system provides for the configuration of subscriber functions that serve as default values when specific attributes are not contained in the individual subscriber’s profile. The following table describes these functions.

Functions Used to Provide “Default” Subscriber Attributes

Function	Description
Subscriber Named default	Within each context, the system creates a subscriber called default. The profile for the subscriber named default provides a configuration template of attribute values for subscribers authenticated in that context. Any subscriber attributes that are not included in a RADIUS-based subscriber profile is configured according to the values for those attributes as defined for the subscriber named default. NOTE: The profile for the subscriber named default is not used to provide missing information for subscribers configured locally.
default subscriber Command	This command in the PDSN, FA, and HA service Configuration modes specifies a profile from a subscriber named something other than default to use a configuration template of attribute values for subscribers authenticated in that context. This command allows multiple services to draw “default” subscriber information from multiple profiles.

‌

When configured properly, the functions described in the table above could be used to apply an ACL to:

•	All subscribers facilitated within a specific context by applying the ACL to the profile of the subscriber named default.

•	All subscribers facilitated by specific services by applying the ACL to a subscriber profile and then using the default subscriber command to configure the service to use that subscriber as the “default” profile.

Applying an ACL to the Subscriber Named default

This section provides information and instructions for applying an ACL to the subscriber named default.

Important: This section provides the minimum instruction set for applying the ACL list to all traffic within a context. For more information on commands that configure additional parameters and options, refer to the Subscriber Configuration Mode Commands chapter in the Command Line Interface Reference.

To configure the system to provide access control list facility to subscribers:

Step 1

Apply the configured access control list by applying the example configuration in the Applying an ACL to the Subscriber Named default section.

Step 2

Verify that ACL is applied properly on interface by following the steps in the Verifying the ACL Configuration to the Subscriber Named default section.

Step 3

Save your configuration as described in the Verifying and Saving Your Configuration chapter in this guide.

 

Applying an ACL to the Subscriber Named default

To example to apply the ACL to the default subscriber, use the following configuration:

configure

  context <acl_ctxt_name> [ -noconfirm ]

     subscriber name <subs_name>

        ip access-group <acl_list_name> [ in | out ]

        end

Notes:

•	The context name is the name of the ACL context containing the interface to which the ACL is to be applied.

•	If neither the in nor the out keyword is specified, the ACL will be applied to all inbound and outbound packets.

•	The ACL to be applied must be configured in the context specified by this command.

•	Up to 8 ACLs can be applied to a group provided that the number of rules configured within the ACL(s) does not exceed the 128-rule limit for the interface.

 

Verifying the ACL Configuration to the Subscriber Named default

These instructions are used to verify the ACL configuration.

Step 1

Verify that your ACL lists were applied properly by entering the following command in Exec Mode:

show configuration context context_name

context_name is the name of the context containing the subscriber default to which the ACL(s) was/were applied.

The output of this command displays the configuration of the entire context. Examine the output for the commands pertaining to interface configuration. The commands display the ACL(s) applied using this procedure.

configure

  context context_name

     ip access-list acl_name

        deny host ip_address

        deny ip any host ip_address

        exit

     ip access-group access_group_name

     service-redundancy-protocol

        exit

     interface interface

        ip address ip_address/mask

        exit

     subscriber name default

        ip access-group access_group_name in

        ip access-group access_group_name out

        exit

     aaa group default

        exit

     gtpp group default

        exit

     content-filtering server-group cfsg_name

        response-timeout response_timeout

        connection retry-timeout retry_timeout

        end

Applying an ACL to Service-specified Default Subscribers

This section provides information and instructions for applying an ACL to the subscriber to be used as the “default” profile by various system services.

Important: This section provides the minimum instruction set for applying the ACL list to all traffic within a context. For more information on commands that configure additional parameters and options, refer the Subscriber Configuration Mode Commands chapter in the Command Line Interface Reference.

To configure the system to provide access control list facility to subscribers:

Step 1

Apply the configured access control list by applying the example configuration in the Applying an ACL to Service-specified Default Subscriber section.

Step 2

Verify that the ACL is applied properly on interface by following the steps in the Verifying the ACL Configuration to Service-specified Default Subscriber section.

Step 3

Save your configuration as described in the Verifying and Saving Your Configuration chapter in this guide.

 

Applying an ACL to Service-specified Default Subscriber

To apply the ACL to a service-specified Default subscriber, use the following configuration:

configure

  context <acl_ctxt_name> [ -noconfirm ]

     { pdsn-service | fa-service | ha-service } <service_name>

        default subscriber <svc_default_subs_name>

        exit

     subscriber name <svc_default_subs_name>

        ip access-group <acl_list_name> [ in | out ]

        end

Notes:

•	The context name is the name of the ACL context containing the interface to which the ACL is to be applied.

•	If neither the in nor the out keyword is specified, the ACL will be applied to all inbound and outbound packets.

•	The ACL to be applied must be configured in the context specified by this command.

•	Up to 8 ACLs can be applied to a group provided that the number of rules configured within the ACL(s) does not exceed the 128-rule limit for the interface.

 

Verifying the ACL Configuration to Service-specified Default Subscriber

To verify the ACL configuration.

Step 1

Verify that your ACL lists were applied properly by entering the following command in Exec Mode:

show configuration context context_name

context_name is the name of the context containing the service with the default subscriber to which the ACL(s) was/were applied.

The output of this command displays the configuration of the entire context. Examine the output for the commands pertaining to interface configuration. The commands display the ACL(s) applied using this procedure.

configure

  context context_name

     ip access-list acl_name

        deny host ip_address

        deny ip any host ip_address

        exit

     ip access-group access_group_name

     interface interface

        ip address ip_address/mask

        exit

     subscriber default

        exit

     subscriber name subscriber_name

        ip access-group access_group_name in

        ip access-group access_group_name out

        exit

     pdsn-service service_name

        default subscriber subscriber_name

        end

 

Applying a Single ACL to Multiple Subscribers via APNs

If IP ACLs are applied to subscribers via attributes in their profile, the subscriber profile could be configured locally on the system or remotely on a RADIUS server.

To reduce configuration time, ACLs can alternatively be applied to APN templates for GGSN subscribers. When configured, any subscriber packets facilitated by the APN template would then have the associated ACL applied.

This section provides information and instructions for applying an ACL to an APN template.

Important: This section provides the minimum instruction set for applying the ACL list to all traffic within a context. For more information on commands that configure additional parameters and options, refer to the Subscriber Configuration Mode Commands chapter in the Command Line Interface Reference.

To configure the system to provide access control list facility to subscribers:

Step 1

Apply the configured access control list by applying the example configuration in the Applying an ACL to Multiple Subscriber via APNs section.

Step 2

Verify that ACL is applied properly on interface by following the steps in the Verifying the ACL Configuration to APNs section.

Step 3

Save your configuration as described in the Verifying and Saving Your Configuration chapter in this guide.

 

Applying an ACL to Multiple Subscriber via APNs

To apply the ACL to multiple subscribers via APN, use the following configuration:

configure

  context <dest_context_name> [ -noconfirm ]

     apn <apn_name>

        ip access-group <acl_list_name> [ in | out ]

        end

Notes:

•	The ACL to be applied must be in the destination context of the APN (which can be different from the context where the APN is configured).

•	If either the in or out keyword is not specified, the command is added to the config file twice, once with in and once with out, and the ACL will be applied to all inbound and outbound packets.

•	Up to 8 ACLs can be applied to a group provided that the number of rules configured within the ACL(s) does not exceed the 128-rule limit for the interface.

 

Verifying the ACL Configuration to APNs

To verify the ACL configuration:

Step 1

Verify that your ACL lists were applied properly by entering the following command in Exec Mode:

show configuration context context_name

context_name is the name of the context containing the APN apn1 having default subscriber to which the ACL(s) was/were applied.

The output of this command displays the configuration of the entire context. Examine the output for the commands pertaining to interface configuration. The commands display the ACL(s) applied using this procedure.

configure

  context context_name

     ip access-list acl_name

        deny host ip_address

        deny ip any host ip_address

        exit

     ip access-group access_group_name

     interface interface

        ip address ip_adrress/mask

        exit

     subscriber default

        exit

     apn apn_name

        ip access-group access_group_name in

        ip access-group access_group_name out

        end

 

 

Appendix D
Congestion Control

 

 

This appendix describes the Congestion Control feature. It covers the following topics:

•

Overview

•	Configuring Congestion Control

Overview

Congestion Control monitors the system for conditions that could potentially degrade performance when the system is under heavy load. Typically, these conditions are temporary (for example, high CPU or memory utilization) and are quickly resolved. However, continuous or large numbers of these conditions within a specific time interval may impact the system’s ability to service subscriber sessions. Congestion control helps identify such conditions and invokes policies for addressing the situation.

Congestion control operation is based on configuring the following:

•

Congestion Condition Thresholds: Thresholds dictate the conditions for which congestion control is enabled and establishes limits for defining the state of the system (congested or clear). These thresholds function in a way similar to operation thresholds that are configured for the system as described in the Thresholding Configuration Guide. The primary difference is that when congestion thresholds are reached, a service congestion policy and an SNMP trap, starCongestion, are generated.

A threshold tolerance dictates the percentage under the configured threshold that must be reached in order for the condition to be cleared. An SNMP trap, starCongestionClear, is then triggered.

•	Port Utilization Thresholds: If you set a port utilization threshold, when the average utilization of all ports in the system reaches the specified threshold, congestion control is enabled.

•	Port-specific Thresholds: If you set port-specific thresholds, when any individual port-specific threshold is reached, congestion control is enabled system-wide.

•	Service Congestion Policies: Congestion policies are configurable for each service. These policies dictate how services respond when the system detects that a congestion condition threshold has been crossed.

Important: This section provides the minimum instruction set for configuring congestion control. Commands that configure additional interface or port properties are provided in the Subscriber Configuration Mode chapter of the Command Line Interface Reference.

Configuring Congestion Control

To configure Congestion Control functionality:

Step 1

Configure congestion control thresholds as described in the Configuring the Congestion Control Threshold section.

Step 2

Configure service congestion policies as described in the Configuring Service Congestion Policies section.

Step 3

Enable redirect overload policies as described in the Enabling Congestion Control Redirect Overload Policy section.

Step 4

Configure disconnecting subscribers based on call or inactivity time as described in the Disconnecting Subscribers Based on Call or Inactivity Time section.

Step 5

Save your configuration as described in the Saving and Verifying Your Configuration chapter in this guide.

Configuring the Congestion Control Threshold

To configure congestion control threshold, apply the following example configuration in the Global Configuration mode of the CLI:

configure

  congestion-control threshold max-sessions-per-service-utilization <percent>

  congestion-control threshold tolerance <percent>

  end

Notes:

 

•	There are several additional threshold parameters. See the Global Configuration Mode chapter of the Command Line Interface Reference for more information.

•	The tolerance is the percentage under a configured threshold that dictates the point at which the condition is cleared.

•	Repeat this configuration as needed for additional thresholds.

Configuring Service Congestion Policies

To create a congestion control policy, apply the following example configuration in the Global Configuration mode of the CLI:

configure

  congestion-control policy <service> action { drop | none | redirect | reject }

  end

Notes:

•	When the redirect action occurs for PDSN services, the PDSN responds to the PCF with a reply code of 136, “unknown PDSN address” along with the IP address of an alternate PDSN.

•	redirect is not available for PDIF.

•	The default action for PDIF is “none.”

•	When the redirect action occurs for HA services, the system responds to the FA with a reply code of 136, “unknown home agent address”.

•	redirect can not be used in conjunction with GGSN services.

•	redirect is not available for the LMA service.

•	When setting the action to reject, the reply code is 130, “insufficient resources”.

•	For the GGSN, the reply code is 199, “no resources available”.

•	For the MME, redirect is not available.

Configuring Overload Reporting on the MME

When an overload condition is detected on an MME and the report-overload keyword is enabled in the congestion-control policy command, the MME reports the condition to a specified percentage of eNodeBs and proceeds to take the configured action on incoming sessions. To create a congestion control policy with overload reporting, apply the following example configuration:

configure

   congestion-control policy mme-service action report-overload reject-new-sessions enodeb-percentage <percentage>

   end

Notes:

•	Other overload actions include permit-emergency-sessions and reject-non-emergency-sessions.

Enabling Congestion Control Redirect Overload Policy

To create a congestion control policy and configure a redirect overload policy for the service, apply the following example configuration:

Important: Redirect is not available on PDIF for this release.

configure

  congestion-control

  context <context_name>

      {service_configuration_mode}

         policy overload redirect address

         end

Notes:

•	Optional: If the congestion control policy action was configured to redirect, then a redirect overload policy must be configured for the service(s) that are affected.

•	There are several service configuration modes that you can configure. See the Command Line Interface Reference for a complete list of modes.

•	You can set various options for redirection. See the Command Line Interface Reference for more information.

•	Repeat this configuration example to configure overload policies for additional services configured in the same context.

Verify the Service Overload Policies

To verify that the service overload policies were properly configured enter the following command in the Exec Mode:

show <service_type> name service_name

This command lists the entire service configuration. Verify that the information displayed for the “Overload Policy” is accurate.

Repeat this configuration example to configure additional services in other contexts.

Verify the Congestion Control Configuration

To verify Congestion Control Configuration enter the show congestion-control configuration command in the Exec Mode.

The following output is a concise listing of all threshold and policy configurations:

Congestion-control: enabled

Congestion-control threshold parameters

system cpu utilization: 80%

service control cpu utilization: 80%

system memory utilization: 80%

message queue utilization: 80%

message queue wait time: 10 seconds

port rx utilization: 80%

port tx utilization: 80%

license utilization: 100%

max-session-per-service utilization: 100%

tolerence limit: 10%

Overload-disconnect: disabled

Overload-disconnect threshold parameters

   license utilization: 80%

   max-session-per-service utilization: 80%

   tolerance: 10%

   session disconnect percent: 5%

   iterations-per-stage: 8

Congestion-control Policy

   pdsn-service: none

   ha-service: none

   lma-service: none

   ggsn-service: none

   closedrp-service: none

   lns-service: none

   cscf-service: reject

   pdif-service: none

   fng-service: none

   sgsn-service: none

   mme-service: drop

   asngw-service: none

   asnpc-service: none

   phsgw-service: none

   phspc-service: none

   mipv6ha-service: none

   lma-service: none

   sgw-service: none

   pgw-service: none

   hnbgw-service: none

   pcc-policy-service: none

   pcc-quota-service: none

   pcc-af-service: none

The primary threshold to observe is license utilization. This threshold is defaulted to 80%. Overload controls on the system enables the Congestion-control Policy when the system has only 80% of the licenses used. The overload condition will not clear until the utilization drops below the tolerance limit setting. The tolerance limit is defaulted to 10%. If the system goes into overload due to license utilization (threshold at 80%), the overload condition will not clear until the license utilization reaches 70%.

The system may go into overload if threshold settings are set too low and congestion control is enabled. You will need to review all threshold values and become familiar with the settings.

Since the recommendation for license utilization overload threshold is 100%, you should enable a license threshold alarm at 80%. An alarm is then triggered when the license utilization hits 80%. When the congestion-control policy setting is set to drop, the system drops incoming packets containing new session requests.

Important: For additional information on configuring the alarm threshold, refer to the Threshold Configuration Guide.

Disconnecting Subscribers Based on Call or Inactivity Time

During periods of heavy system load, it may be necessary to disconnect subscribers in order to maintain an acceptable level of system performance. You can establish thresholds to select subscribers to disconnect based on the length of time that a call has been connected or inactive.

To enable overload disconnect for the currently selected subscriber, use the following configuration example:

configure

   context <context_name>

      subscriber name <subscriber_name>

         default overload-disconnect threshold inactivity-time <dur_thresh>

         default overload-disconnect threshold connect-time <dur_thresh>

         end

To disable the overload disconnect feature for this subscriber, use the following configuration example:

configure

   context <context_name>

      subscriber <subscriber_name>

      no overload-disconnect {[ threshold inactivity-time] | [ threshhold connect-time]}

      end

Notes:

•	overload-disconnect is not supported for the CSCF service.

 

 

Appendix E
Content Service Steering

 

 

This chapter provides information on configuring Content Service Steering (CSS). The product administration guides provide provides examples and procedures for configuration of basic services on the system. You should select the configuration example that best meets your service model, and configure the required elements for that model as described in the respective product administration guide, before using the procedures in this appendix.

Important: Internal CSS is a generic feature, if an ECSv2 license is installed on your system, internal CSS can be enabled. A separate license is not required to enable internal CSS. Contact your local Cisco account representative for information on how to obtain a license.

This chapter contains the following topics:

•

Overview

•	Configuring Internal Content Service Steering

Overview

Content Service Steering (CSS) selectively directs subscriber traffic to In-line services internal to the system based on data content presented by mobile subscribers. CSS is a broad term that includes features such as NAT, HTTP redirection, and DNS redirection.

CSS uses Access Control Lists (ACLs) to redirect subscriber traffic flows. ACLs control the flow of packets into and out of the system. ACLs consist of “rules” (ACL rules) or filters that control the action taken on packets matching the filter criteria.

ACLs are configurable on a per-context basis and applies to a subscriber through either a subscriber profile (or an APN profile in the destination context. For additional information, refer to the Access Control Lists appendix in this guide

Configuring Internal Content Service Steering

To configure and activate a single CSS service for redirecting all of a subscriber’s IP traffic to an internal in-line service:

Step 1

Define an IP ACL as described in the Defining IP Access Lists for Internal CSS section.

Step 2

Optional: Apply an ACL to an individual subscriber as described in the Applying an ACL to an Individual Subscriber (Optional) section.

Step 3

Optional: Apply a single ACL to multiple subscribers as described in the Applying an ACL to Multiple Subscribers (Optional) section.

Step 4

Optional: Apply an ACL to multiple subscribers via APNs as described in the Applying an ACL to Multiple Subscribers via APNs (Optional) section.

Step 5

Save your configuration as described in the Verifying and Saving Your Configuration chapter in this guide.

Important: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands. Not all commands or keywords/variables may be supported or available. Availability varies on the platform type and installed license(s).

Defining IP Access Lists for Internal CSS

IP ACLs specify what type of subscriber traffic and which direction (uplink, downlink, or both) traffic is redirected. The IP ACL must be specified in the context in which subscriber authentication is performed.

Caution: To minimize the risk of data loss, do not make configuration changes to ACLs while the system is facilitating subscriber sessions.

Use the following configuration example to define an IP ACL for internal CSS; start in the Exec mode of the CLI:

configure

  context <context_name>

     ip access-list <acl_name>

        redirect css service <service_name> <keywords> <options>

        end

Notes:

•	<service_name> must be an ACL service name.

•	For information on the keywords and options available with the redirect css service command, see the ACL Configuration Mode Commands chapter of the Command Line Interface Reference.

•	For IPv6 ACLs, the same configurations must be done in the IPv6 ACL Configuration Mode. See the IPv6 ACL Configuration Mode Commands chapter of the Command Line Interface Reference.

Applying an ACL to an Individual Subscriber (Optional)

For information on how to apply an ACL to an individual subscriber, refer to the Applying an ACL to an Individual Subscriber section of the Access Control Lists appendix.

Applying an ACL to Multiple Subscribers (Optional)

IP ACLs are applied to subscribers via attributes in their profiles. The subscriber profile can be configured locally on the system or remotely on a RADIUS server.

The system provides for the configuration of subscriber functions that serve as default values when specific attributes are not contained in the individual subscriber’s profile. When configured properly, the functions can be used to apply an ACL to:

•	All subscribers facilitated within a specific context by applying the ACL to the profile of the subscriber named default.

•	All subscribers facilitated by specific services by applying the ACL to a subscriber profile and then using the default subscriber command to configure the service to use that subscriber as the “default” profile.

Applying an ACL to the Subscriber Named default (Optional)

For information on how to apply an ACL to the default subscriber, refer to the Applying an ACL to the Subscriber Named default section of the Access Control Lists appendix.

Applying an ACL to Service-specified Default Subscribers (Optional)

For information on how to apply an ACL to the subscriber to be used as the “default” profile by various system services, refer to the Applying an ACL to Service-specified Default Subscribers section of the Access Control Lists appendix.

Applying an ACL to Multiple Subscribers via APNs (Optional)

IP ACLs are applied to subscribers via attributes in their profiles. The subscriber profile can be configured locally on the system or remotely on a RADIUS server.

To reduce configuration time, ACLs can alternatively be applied to APN templates. When configured, any subscriber packets facilitated by the APN template would then have the associated ACL applied.

For information on how to apply an ACL to multiple subscribers via APNs, refer to the Applying a Single ACL to Multiple Subscribers via APNs section the Access Control Lists chapter.

 

 

Appendix F
Interchassis Session Recovery

 

 

This appendix describes how to configure Interchassis Session Recovery (ICSR). The product Administration Guides provide examples and procedures for configuration of basic services on the system. You should select the configuration example that best meets your service model, and configure the required elements for that model as described in the respective product Administration Guide, before using the procedures in this appendix.

This appendix discusses the following:

•

Overview

•	ICSR Operation

•	Configuring Interchassis Session Recovery (ICSR)

Caution: ICSR should not be configured on chassis supporting L2TP calls.

Overview

The ICSR feature provides the highest possible availability for continuous call processing without interrupting subscriber services. ICSR allows the operator to configure geographically distant gateways for redundancy purposes. In the event of a node or gateway failure, ICSR allows sessions to be transparently routed around the failure, thus maintaining the user experience. ICSR also preserves session information and state.

ICSR is implemented through the use of redundant chassis. The chassis are configured as primary and backup, with one being active and one standby. Both chassis are connected to the same AAA server. A checkpoint duration timer controls when subscriber data is sent from the active chassis to the standby chassis. If the active chassis handling the call traffic goes out of service, the standby chassis transitions to the active state and continues processing the call traffic without interrupting the subscriber session.

The chassis determine which is active through a propriety TCP-based connection known as the Service Redundancy Protocol (SRP) link. The SRP link is used to exchange Hello messages between the primary and backup chassis and must be maintained for proper system operation.

Important: Refer to the Product Overview to verify whether a specific service supports ICSR as an option.

Interchassis Communication

Chassis configured to support ICSR communicate using periodic Hello messages. These messages are sent by each chassis to notify the peer of its current state. The Hello message contains information about the chassis such as its configuration and priority. A dead interval is used to set a time limit for a Hello message to be received from the chassis’ peer. If the standby chassis does not receive an Hello message from the active chassis within the dead interval, the standby chassis transitions to the active state. In situations where the SRP link goes out of service, a priority scheme is used to determine which chassis processes the session. The following priority scheme is used:

•	route modifier

•	chassis priority

•	SPIO MAC address

Checkpoint Messages

Checkpoint messages are sent from the active chassis to the standby chassis. These messages are sent at specific intervals and contain all the information needed to recreate the sessions on the standby chassis, if that chassis were to become active. Once a session exceeds the checkpoint duration, checkpoint data is collected on the session.

AAA Monitor

AAA servers are monitored using the authentication probe mechanism. AAA servers are considered Up if the authentication-probe receives a valid response. AAA servers are considered Down when the max-retries count specified in the configuration of the AAA server has been reached. The service-redundancy protocol will initiate a switchover when none of the configured AAA servers responds to an authentication probe. AAA probing is only be performed on the active chassis.

Important: A switchover event caused by a AAA monitoring failure is non-revertible. If the newly active chassis fails to monitor the configured AAA servers it remains as the active chassis until one of the following occurs:

•	a manual switchover

•	another non-AAA failure event causes the system to switchover

•	a CLI command is used to clear the AAA failure flag and allow the chassis to switch to standby

BGP Interaction

The Service Redundancy Protocol implements non-revertible switchover behavior via a mechanism that adjusts the route modifier value for the advertised loopback/IP Pool routes. The initial value of the route modifier value is determined by the chassis’ configured role and is initialized to a value that is higher than a normal operational value. This ensures that in the event of an SRP link failure and an SRP task failure, the correct chassis is still preferred in the routing domain.

The Active and Standby chassis share current route modifier values. When BGP advertises the loopback and IP pool routes, it converts the route modifier into an autonomous systems (AS) path prepend count. The Active chassis always has a lower route modifier, and thus prepends less to the AS-path attribute. This causes the route to be preferred in the routing domain.

If communication on the SRP link is lost, and both chassis in the redundant pair are claiming to be Active, the previously Active chassis is still preferred since it is advertising a smaller AS-path into the BGP routing domain. The route modifier is incremented as switchover events occur. A threshold determines when the route modifier should be reset to its initial value to avoid rollover.

Requirements

ICSR configurations require the following:

•	Two chassis configured for the same service types. The services must be bound on an SRP-activated loopback interface.

•	Both chassis must have identical hardware.

•	Three contexts:

•	Redundancy – to configure the primary and backup chassis redundancy.

•	Source – AAA configuration of the specified nas-ip-address must be the IP address of an interface bound to an HA, or any core network service configured within the same context.

•	Destination – to configure monitoring and routing to the PDN.

•	AAA RADIUS server

•	Border Gateway Protocol (BGP) – ICSR uses the route modifier to determine the chassis priority.

Important: ICSR is a licensed feature. Verify that each chassis has the appropriate license before using the procedures in this appendix. To do this, log in to both chassis and execute a show license information command. Look for Inter-Chassis Session Recovery. If the chassis is not licensed, please contact your Cisco account representative.

 

Caution: ICSR should not be configured for chassis supporting L2TP calls.

The following figure shows an ICSR network.

ASR 5000 ICSR Network

ICSR Operation

This section shows operational flows for ICSR.

The following figure shows an ICSR process flow due to a primary failure.

ICSR Process Flow (Primary Failure)

The following figure shows an ICSR process flow due to a manual switchover.

ICSR Process Flow (Manual Switchover)

Chassis Initialization

When the chassis are simultaneously initialized, they send Hello messages to their configured peer. The peer sends a response, establishes communication between the chassis, and messages are sent that contain configuration information.

During initialization, if both chassis are misconfigured in the same mode - both active (primary) or both standby (backup), the chassis with the highest priority (highest number set with the ICSR priority command) becomes active and the other chassis becomes the standby.

If the chassis priorities are the same, the system compares the two MAC addresses and the chassis with the higher SPIO MAC address becomes active. For example, if the chassis have MAC addresses of 00-02-43-03-1C-2B and 00-02-43-03-01-3B, the last 3 sets of octets (the first 3 sets are the vendor code) are compared. In this example, the 03-1C-2B and 03-01-3B are compared from left to right. The first pair of octets in both MAC addresses are the same, so the next pairs are compared. Since the 01 is lower than the 1C, the chassis with the SPIO MAC address of 00-02-43-03-1C-2B becomes active and the other chassis the standby.

Chassis Operation

This section describes how the chassis communicate, maintain subscriber sessions, and perform chassis switchover.

Chassis Communication

If one chassis in the active state and one in the standby state, they both send Hello messages at each hello interval. Subscriber sessions that exceed the checkpoint session duration are included in checkpoint messages that are sent to the standby chassis. The checkpoint message contains subscriber session information so if the active chassis goes out of service, the backup chassis becomes active and is able to continue processing the subscriber sessions. Additional checkpoint messages occur at various intervals whenever subscriber session information is updated on the standby chassis.

Chassis Switchover

If the active chassis goes out of service, the standby chassis continues to send Hello messages. If the standby chassis does not receive a response to the Hello messages within the dead interval, the standby chassis initiates a switchover. During the switchover, the standby chassis begins advertising its srp-activated loopback and pool routes into the routing domain. Once the chassis becomes active, it continues to process existing AAA services and subscriber sessions that had checkpoint information, and is also able to establish new subscriber sessions.

When the primary chassis is back in service, it sends Hello messages to the configured peer. The peer sends a response, establishes communication between the chassis, and sends Hello messages that contain configuration information. The primary chassis receives an Hello message that shows the backup chassis state as active and then transitions to standby. The Hello messages continue to be sent to each peer, and checkpoint information is now sent from the active chassis to the standby chassis at regular intervals.

When chassis switchover occurs, the session timers are recovered. The access gateway session recovery is recreated with the full lifetime to avoid potential loss of the session and the possibility that a renewal update was lost in the transitional checkpoint update process.

Configuring Interchassis Session Recovery (ICSR)

Important: The ICSR configuration must be the same on the primary and backup chassis. If each chassis has a different Service Redundancy Protocol (SRP) configuration, the session recovery feature does not function and sessions cannot be recovered when the active chassis goes out of service.

This section describes how to configure basic ICSR on each chassis. For information on commands that configure additional parameters and options, refer to the Command Line Interface Reference.

Caution: ICSR should not be configured for chassis supporting L2TP calls.

The procedures described below assume the following:

•	The chassis have been installed and configured with core network services.

For more configuration information and instructions on configuring services, refer to the respective product Administration Guide.

•	In addition, the IP address pools must be srp activated.

•	AAA server is installed, configured and accessible by both chassis.

For more information on configuring the AAA server, refer to the AAA Interface Administration and Reference.

•	BGP router installed and configured. See the Routing appendix in this guide for more information on configuring BGP services.

To configure the ICSR on a primary and/or backup chassis:

Step 1

Configure the SRP context by applying the example configuration in the Configuring the Service Redundancy Protocol (SRP) Context section.

Step 2

Modify the source context of the core network service by applying the example configuration in the Modifying the Source Context for ICSR section.

Step 3

Modify the destination context of core network service by applying the example configuration in the Modifying the Destination Context for ICSR section.

Step 4

Optional: Disable bulk statistics collection on the standby system by applying the example configuration in the Disabling Bulk Statistics Collection on a Standby System section.

Step 5

Verify your primary and backup chassis configuration by following the steps in the Verifying the Primary and Backup Chassis Configuration section.

Step 6

Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

 

Configuring the Service Redundancy Protocol (SRP) Context

To configure the system to work with ICSR:

Step 1

Create the chassis redundancy context and bind it to the IP address of the primary chassis by applying the example configuration in the Creating and Binding the SRP Context section.

Step 2

Configure the chassis redundancy context with priority, chassis mode, hello interval, dead-interval and peer IP address by applying the example configuration in the Configuring the SRP Context Parameters section.

Step 3

Configure the SRP context with interface parameters (including interface name, IP address and port number) for interchassis communication by applying the example configuration in the Configuring the SRP Context Interface Parameters section.

Step 4

Verify your SRP context configuration by following the steps in the Verifying SRP Configuration section.

Step 5

Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

Creating and Binding the SRP Context

Use the example below to create the SRP context and bind it to primary chassis IP address:

Important: ICSR is configured using two systems. Be sure to create the redundancy context on both systems. CLI commands must be executed on both systems. Log onto both chassis before continuing. Always make configuration changes on the primary chassis first. Before starting this configuration, identify which chassis to configure as the primary and use that login session.

configure

  context <srp_ctxt_name> [ -noconfirm ]

     service-redundancy-protocol

        bind address <ip_address>

        end

Notes:

•	ICSR should be configured and maintained in a separate context.

•	Be sure to bind the local IP address to the primary chassis. When configuring the backup chassis, be sure to bind the local IP address to the backup chassis.

 

Configuring the SRP Context Parameters

This configuration assigns a chassis mode and priority, and also configures the redundancy link between the primary and backup chassis:

Important: CLI commands must be executed on both chassis. Log onto both chassis before continuing. Always make configuration changes on the primary chassis first.

configure

  context <srp_ctxt_name>

     service-redundancy-protocol

        chassis-mode { primary | backup }

        priority <priority>

        peer-ip-address <ip_address>

        hello-interval <dur_sec>

        dead-interval <dead_dur_sec>

        end

Notes:

•	ICSR should be configured and maintained in a separate context.

•	When assigning the chassis mode on the backup chassis be sure to enter the backup keyword.

•	The priority determines which chassis becomes active when the redundancy link goes out of service. The higher priority chassis has the lower number. Be sure to assign different priorities to each chassis.

•	Enter the IP chassis of the backup chassis as the peer-ip-address to the primary chassis. Assign the IP address of the primary chassis as the peer-ip-address to the backup chassis.

•	The dead-intervalmust be at least three times greater than the hello-interval. For example, if the hello interval is 10, the dead interval should be at least 30. System performance is severely impacted if the hello interval and dead interval are not set properly.

Configuring the SRP Context Interface Parameters

This procedure configures the communication interface with the IP address and port number within the SRP context. This interface supports interchassis communication.

Important: CLI commands must be executed on both chassis. Log onto both chassis before continuing. Always make configuration changes on the primary chassis first.

configure

  context <vpn_ctxt_name> [ -noconfirm ]

     interface <srp_if_name>

        ip-address { <ip_address> | <ip_address>/<mask> }

        exit

     exit

  port ethernet <slot_num>/<port_num>

     description <des_string>

     medium { auto | speed { 10 | 100 | 1000 } duplex { full | half } }

     no shutdown

     bind interface <srp_if_name> <srp_ctxt_name>

     end

Verifying SRP Configuration

Step 1

Verify that your SRP contexts were created and configured properly by entering the show srp info command (Exec Mode).

Sample output for this command as shown. In this example, an SRP context called srp1 was configured with default parameters.

Service Redundancy Protocol:

----------------------------------------------------------------------

Context: srp1

Local Address: 0.0.0.0

Chassis State: Init

Chassis Mode: Backup

Chassis Priority: 125

Local Tiebreaker: 00-00-00-00-00-00

Route-Modifier: 34

Peer Remote Address: 0.0.0.0

Peer State: Init

Peer Mode: Init

Peer Priority: 0

Peer Tiebreaker: 00-00-00-00-00-00

Peer Route-Modifier: 0

Last Hello Message received: -

Peer Configuration Validation: Initial

Last Peer Configuration Error: None

Last Peer Configuration Event: -

Connection State: None

Modifying the Source Context for ICSR

To modify the source context of core service:

Step 1

Add the Border Gateway Protocol (BGP) router AS-path and configure the gateway IP address, neighbor IP address, remote IP address in the source context where the core network service is configured, by applying the example configuration in the Configuring BGP Router and Gateway Address section.

Step 2

Configure the service redundancy context with the BGP neighbor context and IP address to monitor the BGP link activity by applying the example configuration in the Configuring SRP Context for BGP section.

Step 3

Verify your BGP context configuration by following the steps in the Verifying BGP Configuration section.

Step 4

Save your configuration as described in the Verifying and Saving Your Configuration chapter in this guide.

Configuring BGP Router and Gateway Address

Use the following example to create the BGP context and network addresses.

configure

  context <source_ctxt_name>

     router bgp <AS_num>

        network <gw_ip_address>

        neighbor <neighbor_ip_address> remote-as <AS_num>

        end

Notes:

•	source_ctxt_nameis the context where the core network service is configured.

Configuring SRP Context for BGP

Use the following example to configure the BGP context and IP addresses in the SRP context.

configure

  context <srp_ctxt_name>

     service-redundancy-protocol

        monitor bgp context <source_ctxt_name> <neighbor_ip_address>

        end

Verifying BGP Configuration

Step 1

Verify your BGP configuration by entering the show srp monitor bgp command (Exec Mode).

Modifying the Destination Context for ICSR

To modify the destination context of core service:

Step 1

Add the BGP router and configure the gateway IP address, neighbor IP address, remote IP address in the destination context where the core network service is configured, by applying the example configuration in the Configuring BGP Router and Gateway Address in Destination Context section.

Step 2

Configure the service redundancy context with BGP neighbor context and IP address to monitor the BGP link activity by applying the example configuration in the Configuring SRP Context for BGP for Destination Context section.

Step 3

Set the subscriber mode to default by following the steps in the Setting Subscriber to Default Mode section.

Step 4

Verify your BGP context configuration by following the steps in the Verifying BGP Configuration in Destination Context section.

Step 5

Save your configuration as described in the Verifying and Saving Your Configuration chapter in this guide.

Configuring BGP Router and Gateway Address in Destination Context

Use the following example to create the BGP context and network addresses.

configure

  context <dest_ctxt_name>

     router bgp <AS_num>

        network <gw_ip_address>

        neighbor <neighbor_ip_address> remote-as <AS_num>

        end

Notes:

•	AS_num is the autonomous systems path number for this BGP router.

Configuring SRP Context for BGP for Destination Context

Use the following example to configure the BGP context and IP addresses in the SRP context.

configure

  context <srp_ctxt_name>

     service-redundancy-protocol

        monitor bgp context <dest_ctxt_name> <neighbor_ip_address>

        end

Setting Subscriber to Default Mode

Use the following example to set the subscriber mode to default.

configure

  context <dest_ctxt_name>

     subscriber default

     end

Verifying BGP Configuration in Destination Context

Step 1

Verify your BGP configuration by entering the show srp monitor bgp command (Exec Mode).

Disabling Bulk Statistics Collection on a Standby System

You can disable the collection of bulk statistics from a system when it is in the standby mode of operation.

Important: When this feature is enabled and a system transitions to standby state, any pending accumulated statistical data is transferred at the first opportunity. After that no additional statistics gathering takes place until the system comes out of standby state.

Use the following example to disable the bulk statistics collection on a standby system.

configure

  bulkstat mode

     no gather-on-standby

     end

Repeat this procedure for both systems.

Verifying the Primary and Backup Chassis Configuration

This section describes how to compare the ICSR configuration on both chassis.

Step 1

Enter the show configuration srp command on both chassis (Exec mode).

Verify that both chassis have the same SRP configuration information. The output looks similar to following:

config

context source

interface haservice loopback

ip address 172.17.1.1 255.255.255.255 srp-activate

#exit

radius attribute nas-ip-address address 172.17.1.1

radius server 192.168.83.2 encrypted key 01abd002c82b4a2c port 1812

radius accounting server 192.168.83.2 encrypted key 01abd002c82b4a2c port 1813

ha-service ha-pdsn

mn-ha-spi spi-number 256 encrypted secret 6c93f7960b726b6f6c93f7960b726b6f hash-algorithm md5

fa-ha-spi remote-address 192.168.82.0/24 spi-number 256 encrypted secret 1088bdd6817f64df

bind address 172.17.1.1

#exit

#exit

context destination

ip pool dynamic 172.18.0.0 255.255.0.0 public 0 srp-activate

ip pool static 172.19.0.0 255.255.240.0 static srp-activate

#exit

context srp

service-redundancy-protocol

#exit

#exit

end

 

 

Appendix G
QoS Management

 

 

This appendix describes the Quality of Service (QoS) management on Cisco® ASR 5000 chassis and explains how it is configured.

The product Administration Guides provide examples and procedures for configuration of basic services on the system. You should select the configuration example that best meets your service model and configure the required elements for that model as described in the respective product Administration Guide, before using the procedures in this appendix.

This appendix describes the following topics:

•	Introduction

•	Dynamic QoS Renegotiation

•	Network Controlled QoS (NCQoS)

•	Configuring Dynamic QoS Renegotiation

•	Configuring Network Controlled QoS (NCQoS)

•	Monitoring Dynamic QoS Renegotiation Operation

Introduction

The QoS Traffic Policing functionality supported by the GGSN implements QoS for subscribers based on the configuration of the APN template. As a result, all subscriber PDP contexts using the APN receive the same QoS level. This could lead to unused or under-utilized bandwidth by some subscribers thus reducing the amount of resources available to others.

Dynamic QoS Renegotiation

Dynamic QoS Renegotiation minimizes the risk of bandwidth mis-appropriation. This feature allows the GGSN to analyze application traffic, and trigger QoS renegotiation with the SGSN to optimize service performance.

In Dynamic QoS Renegotiation, the GGSN performs packet inspection of application traffic to detect the type of service being utilized and automatically renegotiates the QoS to the appropriate level with a maximum QoS level corresponding to the level granted by the HLR.

QoS renegotiation is performed by sending an Update PDP Context Request to the SGSN. This solution is optimal since the appropriate QoS level is always granted to the subscriber without any requirement on the handset or on the core network. The only prerequisite is QoS renegotiation support on the SGSN. In this model, over reservation of radio resources is avoided, while maintaining the appropriate bandwidth for subscribers with real requirements.

The ASR 5000 supports L7 stateful analysis and QoS Renegotiation. Combining these functionalities results in Dynamic QoS Renegotiation. The system also generates CDRs (or real time charging information) that includes the current QoS information and the service accessed. This enables intelligent application-based charging of services, taking into account the granted QoS. It also enables rebates when it was not possible to provide the QoS level required by an application.

Important: For L7 traffic analysis an ECSv2 license is required.

How Dynamic QoS Renegotiation Works

Implementation of Dynamic QoS Renegotiation involves the following:

•	Initial QoS

•	Service Detection

•	Classification of Application Traffic

•	Quality of Service Renegotiation

Initial QoS

When the session is established, an initial level of QoS must be assigned to the subscriber. The GGSN may either grant the requested QoS, or grant a lower QoS level (minimum or intermediate level). The initial QoS remains in effect until the SGSN or GGSN requests a change. When Dynamic QoS Renegotiation is enabled, there are several conditions when the system would request a QoS change.

•	Services detected that do not need high QoS: After a configurable time period of a subscriber having terminated services that require high QoS, the system could lower the QoS to a value more appropriate to the services actually being used.

•	Services detected that require higher QoS: As soon as a subscriber begins using a service that needs a high QoS, the system immediately attempts to raise the QoS through its service detection capability.

Service Detection

The Application analysis approach to service detection uses application level (L7) information. In the ASR 5000 chassis, application analysis is stateful—keeping track of the application state.

Important: For L7 traffic analysis ECSv2 license is required.

Classification of Application Traffic

Application traffic can be classified into the following: Conversational, Streaming, Interactive 1, Interactive 2, Interactive 3, or Background. Traffic class can be configured in the charging-action, but it does not take direction as a parameter. However, you can configure a rule matching uplink-only or downlink-only packets and associate it with the charging-action.

QoS renegotiation requires knowing what kind of data packets are flowing through for a particular user to associate a given traffic class with the user's current usage pattern. This is done through packet inspection for a subscriber profile via an Access Control List (ACL). Limits for each traffic class can be configured in the APN. The same infrastructure is reused to perform Dynamic QoS Renegotiation.

After classification of traffic and if required by subscriber profile, Dynamic QoS Renegotiation takes place.

 

L4 Packet Inspection

L4 packet analysis has no or low impact on the system performance with very limited impact on system capacity. L4 packet inspection is fully supported by the system.

 

L7 Packet Inspection

L7 packet analysis has a greater impact on system performance with very limited impact on the system capacity. L7 packet inspection involves complete application layer analysis and copes with customized applications.

QoS Renegotiation for a Subscriber QoS Profile

The following is the overall Dynamic QoS Renegotiation process.

1.	When a subscriber attaches to the network, the following happens:

•	Dampening timer is started for the subscriber.

•	QoSI is assigned to the subscriber. This becomes the QoSC till a re-negotiation occurs, as shown in the figure below.

•	The traffic class bitfield is cleared.

2.	As the subscriber starts using some applications, the traffic gets classified on the basis of type of data packets or traffic as mentioned in section Classification of Application Traffic and the corresponding bit in Traffic-class-bitfield is set accordingly.

3.	Following is the mechanics of QoS renegotiation:

•	Examine traffic-class-bitfield to determine the highest bit that is set. This gives the desired QoS Traffic Class (QoSD). The associated uplink/downlink peak-data-rate and guaranteed-data-rate values are taken from the configured parameters for this traffic class in the subscriber APN.

•	If QoSC matches QoSD, no QoS renegotiation is required. Otherwise, it sends an Update PDP Context Request to the SGSN with the QoSD values and QoS renegotiation starts.

•	Reset the dampening timer.

•	The traffic-class-bitfield is cleared.

4.	Following are the conditions under which QoS renegotiation happens:

•	When a higher priority traffic is detected, QoS is renegotiated immediately, without waiting for the dampening time to expire. For example, if the current traffic has a QoS of Interactive and the system detects streaming traffic, QoS is immediately upgraded to Streaming.

•	When the system detects lower priority traffic, it waits for the expiry of the dampening timer before lowering the QoS.

•	During “silence” or no-traffic, QoS renegotiation requests are not initiated.

As seen in the following figure, the QoS profile for the subscriber goes through three renegotiations to match the QoS profile of the highest priority application currently being used.

Dynamic QoS Renegotiation Graph

When there is no traffic, traffic class drops to “Background”, and the corresponding QoS profile is negotiated as described above.

Network Controlled QoS (NCQoS)

Network-controlled QoS is the method by which the system updates the QoS for a PDP context (primary or secondary) upon receipt of Network Requested Update PDP Context (NRUPC) messages from the GGSN. The system can also activate a new secondary PDP context upon receipt of a Network Requested Secondary PDP Context Activation (NRSPCA) message from the GGSN.

How Network Controlled QoS (NCQoS) Works

The GGSN activates or modifies a bearer whenever a service flow matches a statically provisioned Policy and Charging Control (PCC) rule. The network, based on QoS requirements of the application/service, determines what bearers are needed and either modifies an existing bearer or activates a new one.

Statically provisioned PCC rules, called Network Requested Operation (NRO) rules, are configured as charging rules in the Active Charging Service (ACS). As a part of charging action for such rules, QoS-needed and corresponding Traffic Flow Template (TFT) packet filter are configured. QoS-needed mainly consists of QoS Class Identifier (QCI) and data rates. Whereas, TFT mainly consists of uplink and downlink packet filter information.

Warning: This feature does not work in conjunction with IMS-Authorization service.

When a packet arrives, the ACS analyzes it and performs rule matching based on the priority in the rulebase. If an NRO rule bound to the context on which the packet arrived matches, ACS applies the bandwidth limit and gating. If an NRO rule bound to some other context matches, ACS discards the packet.

If an unbound NRO rule matches, ACS finds a context with the same QCI as the NRO rule, where the context’s Maximum Bit Rate (MBR) and matched rule’s MBR (context's MBR + matched rule's MBR) is less than the MBR for that QCI in the APN. If such a context is found, NRUPC for that context is triggered. If the request succeeds, the rule will be bound to that context.

Important: The packet that triggered the NRUPC request is discarded.

If no context satisfying the MBR limit is found, or if there is no context with the same QCI as the NRO rule, the system triggers NRSPCA. If the request succeeds, the rule will be bound to that context.

Important: The packet that triggered the NRSPCA request is discarded.

TFTs from the charging-action associated with the NRO rule are also sent as part of the NRUPC/NRSPCA request, and returned as part of the Create PDP Context Response.

Finally, if a non-NRO rule matches, ACS proceeds with the normal processing of that packet. Non-NRO charging-actions can still do “flow action” or ITC (limit-for-flow-type and limit-for-bandwidth).

ACS also does the following:

•	Before ACS makes an NRUPC/NRSPCA Request, it checks if there is any outstanding request for the same QCI for the same subscriber. If there is, it will not process the new request and discards the packet.

•	After a context is terminated, ACS unbinds all the rules bound to that context. Such a rule can later be bound to some other context when a packet matches that rule.

Important: The packet that triggered the NRUPC/NRSPCA request is discarded.

Configuring Dynamic QoS Renegotiation

This section describes how to configure per-APN based Dynamic QoS Renegotiation.

Caution: For Dynamic QoS Renegotiation, two RADIUS attributes are required for remote subscriber configuration. For a particular subscriber, these attributes can be overridden without considering the timeout for Dynamic QoS Renegotiation and whether Dynamic QoS Renegotiation is enabled or not.

To configure Dynamic QoS Renegotiation:

Step 1

Configure an Access Control List (ACL), as described in the Configuring ACL for Dynamic QoS Renegotiation section.

Step 2

Configure an APN for Dynamic QoS Renegotiation as described in the Configuring APNs for Dynamic QoS Renegotiation section.

Step 3

Save your configuration as described in the Verifying and Saving Your Configuration chapter in this guide.

Step 4

Monitor the operations as described in the Monitoring Dynamic QoS Renegotiation Operation section.

Important: Commands used in the configuration examples in this section reflect base functionality (most common or likely commands and/or keyword options). In many cases, other commands and/or keyword options are available. Refer to the ACS Configuration Mode Commands and APN Configuration Mode Commands sections of the Command Line Interface Reference for complete information regarding all commands.

Configuring ACL for Dynamic QoS Renegotiation

Configuring an ACL and applying it to an APN template are required to specify permission and treatment levels for Dynamic QoS Renegotiation.

Use the following example to configure an ACL for Dynamic QoS Renegotiation:

configure

  context <context_name>

     ip access-list <acl_name>

        permit { tcp | udp } ........ treatment { background | conversational | interactive-1 | interactive-2 | interactive-3 | streaming }

        end

Notes:

•	<context_name> must be the name of the destination context in which you want to configure the ACL. The same context must be used for APN configuration.

•	For information on configuring the rules that comprise the ACL, refer to the Access Control Lists appendix.

Configuring Charging Action for Dynamic QoS Renegotiation

Use the following example to configure charging action parameters for Dynamic QoS Renegotiation support:

configure

  active-charging service <service_name>

     charging-action <charging_action_name> -noconfirm

        qos-renegotiate traffic-class streaming

        flow action discard

        flow limit-for-bandwidth direction downlink peak-data-rate <bps> peak-burst-size <bytes> violate-action lower-ip-precedence

        end

Notes:

•	A maximum of eight packet filters can be configured per charging action.

•	The flow limit-for-bandwidth command contains other option than the example shown here. Refer ti the ACS Charging Action Configuration Mode Commands chapter in the Command Line Interface Reference for more information on this command.

Configuring Rulebase for Dynamic QoS Renegotiation

Use the following example to configure rulebase parameters for Dynamic QoS Renegotiation support:

configure

  active-charging service <service_name>

     rulebase <rulebase_name> [ -noconfirm ]

        qos-renegotiate timeout <timeout>

        end

Configuring APNs for Dynamic QoS Renegotiation

Use the following example to configure an APN template’s QoS profile in support of Dynamic QoS Renegotiation:

configure

  context <context_name>

     apn <apn_name>

        ip access-group <acl_name> [ in | out ]

        end

Notes:

•	<context_name> must be the name of the destination context in which you have already configured the ACL, and want to configure the APN template.

•	<acl_name> must be the name of the ACL that you have already configured in the context.

•	If in the ip access-group command of the APN Configuration Mode, the optional in or out keywords are not specified, the ACL will be applied to all inbound and outbound packets.

Configuring Network Controlled QoS (NCQoS)

To configure NCQoS:

Step 8

Configure packet filter parameters as described in the Configuring Packet Filter for NCQoS section.

Step 9

Configure charging rules and actions as described in the Configuring Charging Action for NCQoS section.

Step 10

Configure APN template and enable bearer control mode for NCQoS as described in the Configuring APN for NCQoS section.

Step 11

Save your configuration as described in the Verifying and Saving Your Configuration chapter.

Step 12

Monitor the operations as described in the Monitoring Dynamic QoS Renegotiation Operation section.

Important: Commands used in the configuration examples in this section implement base functionality (most common or likely commands and/or keyword options). In many cases, other commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.

Configuring Packet Filter for NCQoS

Use the following example to configure packet filter parameters for NCQoS support:

configure

  active-charging service <service_name>

     packet-filter <filter_name> [ -noconfirm ]

        ip local-port { = <port_num> | range <start_port_num> to <end_port_num> }

        ip protocol { = <proto_num> | range <start_proto_num> to <end_proto_num> }

        ip remote-address { = { <ip_address> | <ip_address/mask> } | { range { <ip_address> | <ip_address/mask> } to { <ip_address> | <ip_address/mask> } }

        ip remote-port { = <port_num> | range <start_port_num> to <end_port_num> }

        direction { bi-directional | download | upload }

        priority <priority>

        end

Configuring Charging Action for NCQoS

Use the following example to configure charging action parameters for NCQoS support:

configure

  active-charging service <service_name>

     charging-action <charging_action_name> [ -noconfirm ]

        qos-class-identifier <identifier>

        flow action discard [ downlink | uplink ]

        tft packet-filter <filter_name>

        flow limit-for-bandwidth direction { downlink | uplink } peak-data-rate <bps> peak-burst-size <bytes> violate-action { discard | lower-ip-precedence }

        end

Notes:

•	A number of optional keywords and variable are available for the flow limit-for-bandwidth direction command. Refer to the ACS Charging Action Configuration Mode Commands section of the Command Line Interface Reference for more information regarding this command.

Configuring APN for NCQoS

Use the following example to enable Bearer Control Mode (BCM) for NCQoS support:

configure

  context <context_name>

     apn <apn_name>

        bearer-control-mode [ mixed | ms-only | none ]

        end

Notes:

•	To enable NCQoS, bearer-control-mode in the APN Configuration Mode must be configured with mixed mode.

Monitoring Dynamic QoS Renegotiation Operation

Use the following steps to verify/monitor Dynamic QoS Renegotiation operations:

Step 1

Verify that your APNs were configured properly by entering the following command:

show apn { all | name <apn_name> }

The output is a listing of APN parameter settings.

Step 2

Verify that the ACLs have been properly applied by entering the following command:

show apn name <apn_name>

apn_name must be the name of the APN configured in the Configuring APNs for Dynamic QoS Renegotiation section.The output of this command displays the APN configuration. Examine the output for the ip output access-group and ip input access-group fields. For more details refer to the Applying a Single ACL to Multiple Subscribers section.

Step 3

Verify that your ACL was configured properly by entering the following command:

show ip access-list <acl_name>

The output is a concise listing of IP Access Control List parameter settings.

Step 4

Monitor your QoS renegotiation status for a subscriber by running the show subscriber ggsn-only full command (Exec mode).

The output is a concise listing of subscribers’ settings.

Step 5

For L7 based QoS Renegotiation, view how many time QoS renegotiations have happened for that session by running the show active-charging sessions full all command (Exec mode).

Step 6

View the statistics of APN related to QoS renegotiation parameters by entering the following command:

show apn statistics { all | name <apn_name> }

The output is a listing of APN statistics related to QoS Renegotiation.

Event IDs Pertaining to Dynamic QoS Renegotiation

The Session Manager facility sources event IDs that can be useful for diagnosing errors that could occur when implementing of Dynamic QoS Renegotiation feature.

The following table displays information pertaining to these events.

Event IDs in Session Manager Pertaining to Dynamic QoS Renegotiation

Event	Event ID	Type	Additional Information
QoS Renegotiation timer started for subscriber	10917	Info	“Indicates that the Dynamic QoS Renegotiation timer was started for the subscriber”
QoS Renegotiation timer stopped for subscriber	10918	Info	“Indicates that the Dynamic QoS Renegotiation timer was stopped for the subscriber”
QoS Renegotiation timer expired for subscriber	10919	Info	“Indicates that the Dynamic QoS Renegotiation timer was expired for the subscriber”
QoS Renegotiation message sent for subscriber	10920	Info	“Indicates that the Dynamic QoS Renegotiation message was sent for the subscriber”
L4 classification done for subscriber traffic	10921	Info	“Indicates the kind of L4 classification that was done for the subscriber traffic.”

‌

RADIUS Attributes

The RADIUS attributes listed in the following table are used to enable Dynamic QoS Renegotiation for subscribers configured on remote RADIUS servers. More information on these attributes can be found in the AAA and GTPP Interface Administration and Reference.

RADIUS Attributes Required for Dynamic QoS Renegotiation Support

Attribute	Description
SN-Enable-QoS-Renegotiation (or SN1-Enable-QoS-Renegotiation)	Enables the Dynamic QoS Renegotiation for specific profile application. This attribute displays “enable qos renegotiation”.
SN-QoS-Renegotiation-Timeout (or SN1-QoS-Renegotiation-Timeout)	Timeout duration for dampening time for QoS renegotiation to specific profile application. This attribute displays “qos renegotiation timeout”.

‌

 

 

Appendix H
Routing

 

 

This appendix provides information on configuring an enhanced, or extended, service. The product administration guides provide examples and procedures for configuring basic services on the system. You should select the configuration example that best meets your service model, and configure the required elements for that model before using the procedures in this appendix.

This appendix includes the following sections:

•	Routing Policies

•	Static Routing

•	OSPF Routing

•	Viewing Routing Information

•	Equal Cost Multiple Path (ECMP)

•	BGP-4 Routing

Routing Policies

This section describes how to configure the elements needed to define routing policies. Routing policies modify and redirect routes to and from the system to satisfy specific network deployment requirements.

Use the following building blocks to configure routing policies:

•	Route Access Lists – The basic building block of a routing policy. Route access lists filter routes based on a range of IP addresses.

•	IP Prefix Lists – A more advanced element of a routing policy. An IP Prefix list filters routes based on IP prefixes.

•	AS Path Access Lists – A basic building block used for Border Gateway Protocol (BGP) routing. These lists filter Autonomous System (AS) paths.

•

Route Maps – Route-maps provide detailed control over routes during route selection or route advertisement by a routing protocol, and in route redistribution between routing protocols. For this level of control you use IP Prefix Lists, Route Access Lists and AS Path Access Lists to specify IP addresses, address ranges, and Autonomous System paths.

Creating IP Prefix Lists

Use the following configuration example to create IP Prefix Lists:

  config

    context <context_name>

      ip prefix-list name <list_name> { deny | permit } <network_address/net_mask>

Notes:

•	Set the IP prefix list to deny, permit or match any prefix.

•	IPv4 dotted-decimal and IPv6 colon-separated addresses are supported.

•	Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

Creating Route Access Lists

Use the following procedure to create a Route Access List:

  config

    context <context_name>

       route-access-list { extended identifier } { deny | permit } [ip address ] <ip_address>

       route-access-list named <list_name> { deny | permit } { <ip_address/mask> | any } [ exact-match ]

route-access-list standard identifier { permit | deny } {<ip_address> <wildcard_mask> | any | host <network_address> }

Notes:

•	A maximum of 64 access lists are supported per context.

•	Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

Creating AS Path Access Lists

Use the following procedure to create an AS Path Access List:

config

  context     <context_name>

ip as-path access-list <list_name> [ { deny | permit } <reg_expr> ]

Notes:

•	Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

Creating Route Maps

Use the following configuration example to create a Route Map:

  config

    context <context_name>

       route-map< map_name > { deny | permit } < seq_number >

Notes:

•	Use the match and set commands in Route Map Configuration mode to configure the route map. Refer to the Command Line Interface Reference for more information on these commands.

•	Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

Sample Configuration

The example below shows a configuration that creates two route access lists, applies them to a route map, and uses that route map for a BGP router neighbor.

config

  context isp1

     route-access-list named RACLin1a permit 88.151.1.0/30

     route-access-list named RACLin1a permit 88.151.1.4/30

     route-access-list named RACLany permit any

     route-map RMnet1 deny 100

        match ip address route-access-list RACLin 1 a

        #exit

        route-map RMnet1 deny 200

        match ip address route-access-list RACLin 1 b

        #exit

     route-map RMnet1 permit 1000

        match ip address route-access-list RACLany

        #exit

     router bgp 1

        neighbor 152.20.1.99 as-path 101

        neighbor 152.20.1.99 route-map RMnet1

Static Routing

The system supports static network route configuration on a per context basis. Define network routes by specifying the:

•	IP address and mask for the route

•	Name of the interface in the current context that the route must use

•	Next hop IP address

Adding Static Routes to a Context

To add static routes to a context configuration, you must know the names of the interfaces that are configured in the current context. Use the show ip interface command to list the interfaces in the current context (Exec mode).

Information for all interfaces configured in the current context is displayed as shown in the following example.

[ local ]< host_name > #show ip interface

Intf Name: Egress 1

Description:

IP State: Up (Bound to 24/1 untagged ifIndex 402718721)

IP Address: 192.168.231.5

Subnet Mask: 255.255.255.0

Bcast Address: 192.168.231.255

MTU: 1500

Resoln Type: ARP ARP timeout: 3600 secs

L3 monitor LC-port switchover: Disabled

Number of Secondary Addresses: 0

Total interface count: 1

The first line of information for each interface lists the interface name for the current context as shown in the example output. In this example, there is one interface with the name Egress 1.

config

context <context_name>

ip route { < ip_address | ip_mask > | < ip_addr_mask_combo > } { next-hop } < next_hop_address > | < egress_name > [ precedence ] < precedence > [ cost ] < cost >

Notes:

You can configure a maximum of 1,200 static routes per context. Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

Deleting Static Routes From a Context

Use the following configuration example to remove static routes from a context’s configuration:

config

context context_name

no ip route { < ip_address > < ip_mask > | < ip_addr_mask_combo > } < next_hop_address > < egress_name > [ precedence < precedence > ] [ cost < cost > ]

Notes:

•	Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

 

OSPF Routing

This section gives an overview of Open Shortest Path First (OPSF) routing and its implementation in the system. It also describes how to enable the base OSPF functionality and lists the commands that are available for more complex configurations.

You must purchase and install a license key before you can use this feature. Contact your Cisco account representative for more information on licenses.

Important: During system task recovery, it is possible for a dynamically-learned forwarding entry to incorrectly remain in the system forwarding table if that forwarding entry has been removed from the dynamic routing protocol during the recovery.

OSPF Version 2 Overview

OSPF is a link-state routing protocol that employs an interior gateway protocol (IGP) to route IP packets using the shortest path first based solely on the destination IP address in the IP packet header. OSPF routed IP packets are not encapsulated in any additional protocol headers as they transit the network.

An Autonomous System (AS), or Domain, is defined as a group of networks within a common routing infrastructure.

OSPF is a dynamic routing protocol that quickly detects topological changes in the AS (such as router interface failures) and calculates new loop-free routes after a period of convergence. This period of convergence is short and involves a minimum of routing traffic.

In a link-state routing protocol, each router maintains a database, referred to as the link-state database, that describes the Autonomous System's topology. Each participating router has an identical database. Each entry in this database is a particular router's local state (for example, the router's usable interfaces and reachable neighbors). The router distributes its local state throughout the AS by flooding.

All routers run the same algorithm in parallel. From the link-state database, each router constructs a tree of shortest paths with itself as root to each destination in the AS. Externally derived routing information appears on the tree as leaves. The cost of a route is described by a single dimensionless metric.

OSPF allows sets of networks to be grouped together. Such a grouping is called an area. The topology of this area is hidden from the rest of the AS, which enables a significant reduction in routing traffic. Also, routing within the area is determined only by the area’s own topology, lending the area protection from bad routing data. An area is a generalization of an IP subnetted network.

OSPF enables the flexible configuration of IP subnets so that each route distributed by OSPF has a destination and mask. Two different subnets of the same IP network number may have different sizes (that is, different masks). This is commonly referred to as variable-length subnetting. A packet is routed to the best (longest or most specific) match. Host routes are considered to be subnets whose masks are “all ones” (0xffffffff).

OSPF traffic can be authenticated or non-authenticated, or can use no authentication, simple/clear text passwords, or MD5-based passwords. This means that only trusted routers can participate in the AS routing. You can specify a variety of authentication schemes and, in fact, you can configure separate authentication schemes for each IP subnet.

Externally derived routing data (for example, routes learned from an exterior protocol such as BGP) is advertised throughout the AS. This externally derived data is kept separate from the OSPF ink state data.

Each external route can also be tagged by the advertising router, enabling the passing of additional information between routers on the boundary of the AS.

OSPF uses a link-state algorithm to build and calculate the shortest path to all known destinations.

Basic OSPFv2 Configuration

This section describes how to implement basic OSPF routing.

Enabling OSPF Routing For a Specific Context

Use the following configuration example to enable OSPF Routing for a specific context:

config

  context <context_name>

     router ospf

     end

Notes:

•	Save your configuration as described in the Verifying and Saving Your Configuration chapter in this guide.

Enabling OSPF Over a Specific Interface

After you enable OSPF, specify the networks on which it will run. Use the following command to enable OSPF:

network < network_ip_address > / < network_mask > area {< area_id > | < area_ip_address > }

Important: The default cost for OSPF on the system is 10. To change the cost, refer to the ip ospf cost command in the Ethernet Interface Configuration Commands section of the Command Line Interface Reference.

Notes:

•	Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

Redistributing Routes Into OSPF (Optional)

Redistributing routes into OSPF means any routes from another protocol that meet specified a specified criterion, such as route type, metric, or rule within a route-map, are redistributed using the OSPFv2 protocol to all OSPF areas. This is an optional configuration.

config

  context < context_name >

     router ospf

        redistribute { connected | rip | static }

        end

Notes:

•	Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

Confirming OSPF Configuration Parameters

To confirm the OSPF router configuration, use the following command and look for the section labeled router ospf in the screen output:

show config context < ctxt_name > [ verbose ]

Viewing Routing Information

To view routing information for the current context, run one of the following Exec mode commands;

•	show ip route: Displays information for all types of routes in the current contexts routing table.

•	show ip static-route: Displays information only for static routes in the current contexts routing table.

•	show ip ospf: Displays OSPF process summary information in the current context.

This example shows sample output of the command, show ip route.

[local]host_name# show ip route

"*" indicates the Best or Used route. Destination Nexthop Protocol Prec Cost Interface

*44.44.44.0/24 208.230.231.50 static 1 0 local1

*192.168.82.0/24 0.0.0.0 connected 0 0

*192.168.83.0/24 0.0.0.0 connected 0 0

208.230.231.0/24 0.0.0.0 ospf 110 10 local1

*208.230.231.0/24 0.0.0.0 connected 0 0 local1

Total route count: 5

Equal Cost Multiple Path (ECMP)

The system supports ECMP for routing protocols. ECMP distributes traffic across multiple routes that have the same cost to lessen the burden on any one route.

config

  context < context_name >

     ip routing maximum-paths [ max_no ]

Notes:

•	Save your configuration as described in the Verifying and Saving Your Configuration chapter in this guide.

BGP-4 Routing

The Border Gateway Protocol 4 (BGP-4) routing protocol is supported through a BGP router process that is implemented at the context level.

The Border Gateway Protocol (BGP) is an inter-AS routing protocol. An Autonomous System (AS) is a set of routers under a single technical administration that use an interior gateway protocol and common metrics to route packets within the AS. The set of routers uses an exterior gateway protocol to route packets to other ASs.

BGP runs over TCP. This eliminates the need for the BGP protocol to implement explicit update fragmentation, retransmission, acknowledgement, and sequencing information. Any authentication scheme used by TCP may be used in addition to BGP’s own authentication mechanisms.

BGP routers exchange network reachability information with other BGP routers. This information builds a picture of AS connectivity from which routes are filtered and AS-level policy decisions are enforced.

BGP-4 provides classless inter-domain routing. This includes support for advertising an IP prefix and eliminates the concept of network class within BGP. BGP-4 also allows the aggregation of routes, including the aggregation of AS paths.

Overview of BGP Support

Mobile devices communicate to the Internet through Home Agents (HAs). HAs assign IP addresses to the mobile node from a configured pool of addresses. These addresses are also advertised to Internet routers through an IP routing protocol to ensure dynamic routing. The BGP-4 protocol is used as a monitoring mechanism between an HA and Internet router with routing to support Interchassis Session Recovery (ICSR). (Refer to the Interchassis Session Recovery appendix in this guide for more information.)

The objective of BGP-4 protocol support is to satisfy routing requirements and monitor communications with Internet routers. BGP-4 may trigger an active to standby switchover to keep subscriber services from being interrupted.

The following BGP-4 features are supported:

•	Exterior Border Gateway Protocol (EBGP) multi-hop

•	Route Filtering for inbound and outbound routes

•	Route redistribution and route-maps

IP pool routes and loopback routes are advertised in the BGP domain in the following ways:

•

Through BGP Configuration Mode redistribution commands, all or some of the connected routes are redistributed into the BGP domain. (IP pool and loopback routes are present in the IP routing table as connected routes.) The network routemap command provides the flexibility to change many BGP attributes.

•

Through the BGP Configuration Mode network commands, connected routes are explicitly configured for advertisement into the BGP domain. The network routemap command provides the flexibility to change many BGP attributes. Refer to the Border Gateway Protocol Configuration Mode Commands section of the Command Line Interface Reference for details on these commands.

Important: If a BGP task restarts because of a processing card failure, a migration, a crash, or the removal of a processing card, all peering session and route information is lost.

Configuring BGP

This section describes how to configure and enable basic BGP routing support in the system.

config

  context <context_name>

     router { ospf | bgp < as_number >

        neighbor < IP_address > { remote-as < AS_num > }

Notes:

•	A maximum of 64 BGP peers are supported per context.

•	Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

Redistributing Routes Into BGP (Optional)

Redistributing routes into BGP simply means that any routes from another protocol that meet a specified criterion, such as a route type, or a rule within a route-map, are redistributed through the BGP protocol to all BGP areas. This is an optional configuration.

config

  context <context_name>

     router{ ospf | bgp < as_number > }

        redistribute{bgp | connected | static } [ metric ] < metric_value > ] [ metric-type ] {1 | 2 } ] [ route-map ] < route_map_name ]

Notes:

•	The redistribution options are connected, ospf, rip, or static. Refer to the Border Gateway Protocol Configuration Mode Commands section of the Command Line Interface Reference for details on the redistribute command.

•	A maximum of 64 route-maps are supported per context.

•	Save your configuration as described in Verifying and Saving Your Configuration chapter of this guide.

 

 

Appendix I
Session Recovery

 

 

With robust hardware failover and redundancy protection, any card-level hardware failures on the system can quickly be corrected. However, software failures can occur for numerous reasons, often without prior indication.

This appendix describes the Session Recovery feature that provides seamless failover and reconstruction of subscriber session information in the event of a hardware or software fault.

This appendix includes the following sections:

•	How Session Recovery Works

•	Additional Hardware Requirements

•	Configuring the System to Support Session Recovery

How Session Recovery Works

This section provides an overview of how this feature is implemented and the recovery process.

The Session Recovery feature provides seamless failover and reconstruction of subscriber session information in the event of a hardware or software fault within the system preventing a fully connected user session from being disconnected.

Session recovery is performed by mirroring key software processes (for example, session manager and AAA manager) within the system. These mirrored processes remain in an idle state (standby-mode) wherein they perform no processing, until they may be needed in the event of a software failure (for example, a session manager task aborts).

The system spawns new instances of “standby mode” session and AAA managers for each active control processor (CP) being used. These mirrored processes require both memory and processing resources, which means that additional hardware may be required to enable this feature (see the Additional Hardware Requirements section).

Other key system-level software tasks, such as VPN manager, are performed on a physically separate packet processing card to ensure that a double software fault (for example, session manager and VPN manager fails at same time on same card) cannot occur. The packet processing card that hosts the VPN manager process is in active mode and reserved by the operating system for this sole use when session recovery is enabled.

There are two modes of session recovery.

•

Task recovery mode: Wherein one or more session manager failures occur and are recovered without the need to use resources on a standby packet processing card. In this mode, recovery is performed by using the mirrored “standby-mode” session manager task(s) running on active packet processing cards. The “standby-mode” task is renamed, made active, and is then populated using information from other tasks such as AAA manager. In case of Task failure, limited subscribers will be affected and will suffer outage only until the task starts back up.

•

Full packet processing card recovery mode: Used when a packet processing card hardware failure occurs, or when a planned packet processing card migration fails. In this mode, the standby packet processing card is made active and the “standby-mode” session manager and AAA manager tasks on the newly activated packet processing card perform session recovery.

Session/Call state information is saved in the peer AAA manager task because each AAA manager and session manager task is paired together. These pairs are started on physically different packet processing cards to ensure task recovery.

There are some situations wherein session recovery may not operate properly. These include:

•	Additional software or hardware failures occur during the session recovery operation. For example, an AAA manager fails while the state information it contained was being used to populate the newly activated session manager task.

•	A lack of hardware resources (packet processing card memory and control processors) to support session recovery.

Important: After a session recovery operation, some statistics, such as those collected and maintained on a per manager basis (AAA Manager, Session Manager, etc.) are in general not recovered, only accounting and billing related information is checkpointed and recovered.

Session Recovery is available for the following functions:

•	Any session needing L2TP LAC support (excluding regenerated PPP on top of an HA/GGSN session)

•	Closed RP PDSN services supporting simple IP, Mobile IP, and Proxy Mobile IP

•	CSCF sessions

•	GGSN services for IPv4 and PPP PDP contexts

•	HA services supporting Mobile IP and/or Proxy Mobile IP session types with or without per-user Layer 3 tunnels

•	HNB-GW: HNB Session over IuH

•	HNB-GW: HNB-CN Session over IuPS and IuCS

•	HNB-GW: SeGW Session IPSec Tunnel

•	HSGW services for IPv4

•	IPSG-only systems

•	LNS session types

•	PDSN services supporting simple IP, Mobile IP, and Proxy Mobile IP

•	P-GW services for IPv4

•	SGSN services (3G and 2.5G services) for IPv4 and PPP PDP contexts

Session recovery is not supported for the following functions:

•	Any session using IPv6 (PDSN/GGSN/SGSN/LNS)

•	Any session needing L2TP LAC support (including regenerated PPP on top of an HA/GGSN session)

•	Destination-based accounting recovery

•	GGSN network initiated connections

•	GGSN session using more than 1 service instance

•	MIP/L2TP with IPSec integration

•	MIP session with multiple concurrent bindings

•	Mobile IP sessions with L2TP

•	Multiple MIP sessions

Important: Session Recovery requires the purchase of a license key. Contact your Cisco account representative for more information.

When session recovery occurs, the system reconstructs the following subscriber information:

•	Data and control state information required to maintain correct call behavior.

•	A minimal set of subscriber data statistics; required to ensure that accounting information is maintained.

•	A best-effort attempt to recover various timer values such as call duration, absolute time, and others.

•	The idle time timer is reset to zero and the re-registration timer is reset to its maximum value for HA sessions to provide a more conservative approach to session recovery.

Important: Any partially connected calls (for example, a session where HA authentication was pending but has not yet been acknowledged by the AAA server) are not recovered when a failure occurs.

Additional Hardware Requirements

Because session recovery requires numerous hardware resources, such as memory, control processors, NPU processing capacity, etc., some additional hardware may be required to ensure that enough resources are available to fully support this feature.

Important: A minimum of four packet processing cards (three active and one standby) per individual chassis is required to use this feature.

To allow for complete session recovery in the event of a hardware failure during a packet processing card migration, a minimum of three active packet processing cards and two standby packet processing cards should be deployed.

To assist you in your network design and capacity planning, consider the following factors:

•	Subscriber capacity is decreased depending on the hardware configuration. A fully configured chassis would experience a smaller decrease in subscriber capacity versus a minimally configured chassis.

•	The amount by which control transaction processing capacity is reduced.

•	The reduction in subscriber data throughput.

•	The recovery time for a failed software task.

•	The recovery time for a failed packet processing card.

A packet processing card migration may temporarily impact session recovery as hardware resources (memory, processors, etc.) that may be needed are not available during the migration. To avoid this condition, a minimum of two standby packet processing cards should be configured.

Configuring the System to Support Session Recovery

The following procedures allow you to configure the session recovery feature for either an operational system that is currently in-service (able to accept incoming calls) or a system that is out-of-service (not part of your production network and, therefore, not processing any live subscriber/customer data).

Important: The session recovery feature, even when the feature use key is present, is disabled by default on the system.

Enabling Session Recovery

As noted earlier, session recovery can be enabled on a system that is out-of-service (OOS) and does not yet have any contexts configured, or on an in-service system that is currently capable of processing calls. However, if the system is in-service, it must be restarted before the session recovery feature takes effect.

Enabling Session Recovery on an Out-of-Service System

The following procedure is for a system that does not have any contexts configured.

To enable the session recovery feature on an out-of-service system, follow the procedure below. This procedure assumes that you begin at the Exec mode prompt.

Step 1

At the Exec mode prompt, verify that the session recovery feature is enabled by the session and feature use license on the system by running the show license info command:

The output of this command appears similar to the example shown below. Note that the session recovery feature is bold-faced in this example.

Key Information (installed key):

   Comment                <Host Name>

   CF Device 1            Model: "SanDiskSDCFB-512"

                          Serial Number: "115212D1904T0314"

   CF Device 2            Model: "SanDiskSDCFB-512"

                          Serial Number: "115206D1904S5951"

   Date of Issue          Thursday May 12 14:35:50 EDT 2005

   Issued By              <Vendor Name>

   Key Number             17120

Enabled Features:

   Part Number  Quantity  Feature

   -----------  --------  -----------------------

   xxx-xx-xxxx        15  PDSN/GGSN/SGSN (10K)

        [none]        -   FA         

        [none]        -   IPv4 Routing Protocols

   xxx-xx-xxxx        -   IPSec

   xxx-xx-xxxx        -   2TP LAC (PDSN/GGSN/SGSN)

   xxx-xx-xxxx        1   L2TP LNS (10K)

   xxx-xx-xxxx        6   L2TP LNS (1K)

   xxx-xx-xxxx        -   Session Recovery (PDIF/PDSN/GGSN/SGSN)

        [none]         - Session Recovery (HA)

   xxx-xx-xxxx        -   PCF Monitoring

   xxx-xx-xxxx        -   Layer 2 Traffic Management

 Session Limits:

                Sessions  Session Type

                --------  -----------------------

                  150000  PDSN/GGSN/SGSN

 Status:

                   16000  L2TP LNS

   CF Device 1            Does not match either SPC

   CF Device 2            Does not match either SPC

   License Status         Good (Not Redundant)

Important: If the current status of the Session Recovery feature is Disabled, you cannot enable this feature until a license key is installed in the system.

Step 2

Use the following configuration example to enable session recovery.

configure

   require session recovery

   end

Step 3

Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

The system, when started, enables session recovery, creates all mirrored “standby-mode” tasks, and performs packet processing card reservations and other operations automatically.

Step 4

After the system has been configured and placed in-service, you should verify the preparedness of the system to support this feature as described in the Viewing Session Recovery Status section.

Enabling Session Recovery on an In-Service System

When enabling session recovery on a system that already has a saved configuration, the session recovery commands are automatically placed before any service configuration commands in the configuration file.

To enable the session recovery feature on an in-service system, follow the procedure below. This procedure assumes that you begin at the Exec mode prompt.

Step 2

At the Exec mode prompt, verify that the session recovery feature is enabled by the session and feature use license on the system by running the show license info command:

The output of this command appears similar to the example shown below. Note that the session recovery feature is bold-faced in this example.

Key Information (installed key):

   Comment                <Host Name>

   CF Device 1            Model: "SanDiskSDCFB-512"

                          Serial Number: "115212D1904T0314"

   CF Device 2            Model: "SanDiskSDCFB-512"

                          Serial Number: "115206D1904S5951"

   Date of Issue          Thursday May 12 14:35:50 EDT 2005

   Issued By              <Vendor Name>

   Key Number             17120

Enabled Features:

   Part Number  Quantity  Feature

   -----------  --------  -----------------------

   xxx-xx-xxxx        15  PDSN/GGSN/SGSN (10K)

        [none]        -   FA         

        [none]        -   IPv4 Routing Protocols

   xxx-xx-xxxx        -   IPSec

   xxx-xx-xxxx        -   2TP LAC (PDSN/GGSN/SGSN)

   xxx-xx-xxxx        1   L2TP LNS (10K)

   xxx-xx-xxxx        6   L2TP LNS (1K)

   xxx-xx-xxxx        -   Session Recovery (PDIF/PDSN/GGSN/SGSN)

        [none]         - Session Recovery (HA)

   xxx-xx-xxxx        -   PCF Monitoring

   xxx-xx-xxxx        -   Layer 2 Traffic Management

 Session Limits:

                Sessions  Session Type

                --------  -----------------------

                  150000  PDSN/GGSN/SGSN

 Status:

                   16000  L2TP LNS

   CF Device 1            Does not match either SPC

   CF Device 2            Does not match either SPC

   License Status         Good (Not Redundant)

Important: If the current status of the Session Recovery feature is Disabled, you cannot enable this feature until a license key is installed in the system.

Step 3

Use the following configuration example to enable session recovery.

configure

   require session recovery

   end

Important: This feature does not take effect until after the system has been restarted.

Step 4

Save your configuration as described in the Verifying and Saving Your Configuration. chapter of this guide.

Step 5

Perform a system restart by entering the reload command:

The following prompt appears:

Are you sure? [Yes|No]:

Confirm your desire to perform a system restart by entering yes.

The system, when restarted, enables session recovery and creates all mirrored “standby-mode” tasks, performs packet processing card reservations, and other operations automatically.

Step 6

After the system has been restarted, you should verify the preparedness of the system to support this feature as described in the Viewing Session Recovery Status section.

Important: More advanced users may opt to simply insert the require session recovery command syntax into an existing configuration file using a text editor or other means, and then applying the configuration file manually. Exercise caution when doing this to ensure that this command is placed among the first few lines of any existing configuration file; it must appear before the creation of any non-local context.

Disabling the Session Recovery Feature

To disable the session recovery feature on a system, enter the no require session recovery command from the Global Configuration mode prompt.

Important: If this command is issued on an in-service system, then the system must be restarted by issuing the reload command.

Viewing Session Recovery Status

To determine if the system is capable of performing session recovery, when enabled, enter the show session recovery status verbose command from the Exec mode prompt.

The output of this command should be similar to the examples shown below.

 

[local]host_name# show session recovery status

Session Recovery Status:

  Overall Status         : SESSMGR Not Ready For Recovery

  Last Status Update     : 1 second ago

 

[local]host_name# show session recovery status

Session Recovery Status:

  Overall Status         : Ready For Recovery

  Last Status Update     : 8 seconds ago

 

[local]host_name# show session recovery status verbose

Session Recovery Status:

  Overall Status         : Ready For Recovery

  Last Status Update     : 2 seconds ago

 

              ----sessmgr---     ----aaamgr----     demux

 cpu state    active  standby    active  standby    active  status

---- -------  ------  -------    ------  -------    ------  ------------

 1/1 Active   2       1          1       1          0       Good

 1/2 Active   1       1          0       0          0       Good

 1/3 Active   1       1          3       1          0       Good

 2/1 Active   1       1          1       1          0       Good

 2/2 Active   1       1          0       0          0       Good

 2/3 Active   2       1          3       1          0       Good

 3/0 Active   0       0          0       0          1       Good (Demux)

 3/2 Active   0       0          0       0          1       Good (Demux)

 4/1 Standby  0       2          0       1          0       Good

 4/2 Standby  0       1          0       0          0       Good

 4/3 Standby  0       2          0       3          0       Good

 

[local]host_name#

Viewing Recovered Session Information

To view session state information and any session recovery status, enter the following command:

show subscriber debug-info {callid | msid | username}

Keyword/Variable	Description
callid id	Displays subscriber information for the call specified by id. The call ID must be specified as an 8-byte hexadecimal number.
msid id	Displays information for the mobile user identified by id. id must be from 7 to 16 digits specified as an IMSI, MIN, or RMI. Wildcard characters $ and * are allowed. The * wildcard matches multiple characters and the $ wildcard matches a single character. If you do not want the wildcard characters interpreted as a wildcard enclose them in single quotes ( ‘ ). For example; ‘$’.
username name	Displays information for connections for the subscriber identified by name. The user must have ben previously configured. name must be a sequence of characters and/or wildcard characters ('$' and '*') from 1 to 127 characters in length. The * wildcard matches multiple characters and the $ wildcard matches a single character. If you do not want the wildcard characters interpreted as wildcard enclose them in single quotes ( ‘). For example; ‘$’.

‌

The following example shows the output of this command both before and after a session recovery operation has been performed. The “Redundancy Status” fields in this example have been bold-faced for clarity.

username: user1       callid: 01ca11b1         msid: 0000100003

  Card/Cpu: 4/2

  Sessmgr Instance: 7

  Primary callline:

  Redundancy Status: Original Session

  Checkpoints    Attempts    Success    Last-Attempt    Last-Success

     Full:             69         68         29800ms         29800ms

     Micro:           206        206         20100ms         20100ms

   Current state: SMGR_STATE_CONNECTED

   FSM Event trace:

         State                            Event

         SMGR_STATE_OPEN                  SMGR_EVT_NEWCALL

         SMGR_STATE_NEWCALL_ARRIVED       SMGR_EVT_ANSWER_CALL

         SMGR_STATE_NEWCALL_ANSWERED      SMGR_EVT_LINE_CONNECTED

         SMGR_STATE_LINE_CONNECTED        SMGR_EVT_LINK_CONTROL_UP

         SMGR_STATE_LINE_CONNECTED        SMGR_EVT_AUTH_REQ

         SMGR_STATE_LINE_CONNECTED        SMGR_EVT_IPADDR_ALLOC_SUCCESS

         SMGR_STATE_LINE_CONNECTED        SMGR_EVT_AUTH_SUCCESS

         SMGR_STATE_LINE_CONNECTED        SMGR_EVT_UPDATE_SESS_CONFIG

         SMGR_STATE_LINE_CONNECTED        SMGR_EVT_LOWER_LAYER_UP

  Data Reorder statistics

  Total timer expiry:            0         Total flush (tmr expiry):    0

      Total no buffers:          0         Total flush (no buffers):    0

      Total flush (queue full):  0         Total flush (out of range):  0

      Total flush (svc change):  0         Total out-of-seq pkt drop:   0

      Total out-of-seq arrived:  0

  IPv4 Reassembly Statistics:

       Success:                  0         In Progress: 0

       Failure (timeout):        0         Failure (no buffers): 0

       Failure (other reasons):  0

  Redirected Session Entries:

 

       Allowed:                  2000      Current:                   0

       Added:                    0        Deleted:                  0

       Revoked for use by different subscriber: 0

  Peer callline:

  Redundancy Status: Original Session

  Checkpoints    Attempts    Success    Last-Attempt    Last-Success

     Full:              0          0             0ms             0ms

     Micro:             0          0             0ms             0ms

   Current state: SMGR_STATE_CONNECTED

   FSM Event trace:

         State                            Event

         SMGR_STATE_LINE_CONNECTED        SMGR_EVT_LOWER_LAYER_UP

         SMGR_STATE_CONNECTED             SMGR_EVT_AUTH_REQ

         SMGR_STATE_CONNECTED             SMGR_EVT_AUTH_SUCCESS

         SMGR_STATE_CONNECTED             SMGR_EVT_REQ_SUB_SESSION

         SMGR_STATE_CONNECTED             SMGR_EVT_RSP_SUB_SESSION

         SMGR_STATE_CONNECTED             SMGR_EVT_ADD_SUB_SESSION

         SMGR_STATE_CONNECTED             SMGR_EVT_AUTH_REQ

         SMGR_STATE_CONNECTED             SMGR_EVT_AUTH_SUCCESS

         SMGR_STATE_CONNECTED             SMGR_EVT_AUTH_REQ

         SMGR_STATE_CONNECTED             SMGR_EVT_AUTH_SUCCESS

         SMGR_STATE_CONNECTED             SMGR_EVT_AUTH_REQ

         SMGR_STATE_CONNECTED             SMGR_EVT_AUTH_SUCCESS

         SMGR_STATE_CONNECTED             SMGR_EVT_AUTH_REQ

         SMGR_STATE_CONNECTED             SMGR_EVT_AUTH_SUCCESS

         SMGR_STATE_CONNECTED             SMGR_EVT_AUTH_REQ

         SMGR_STATE_CONNECTED             SMGR_EVT_AUTH_SUCCESS

  Data Reorder statistics

         Total timer expiry:       0         Total flush (tmr expiry): 0

         Total no buffers:         0         Total flush (no buffers): 0

         Total flush (queue full): 0         Total flush (out of range):0

         Total flush (svc change): 0         Total out-of-seq pkt drop: 0

         Total out-of-seq arrived: 0

  IPv4 Reassembly Statistics:

         Success:                  0         In Progress:               0

         Failure (timeout):        0         Failure (no buffers):      0

         Failure (other reasons):  0

  Redirected Session Entries:

         Allowed:               2000         Current:                  0

         Added:                    0         Deleted:                  0

         Revoked for use by different subscriber: 0

Notice that is the example above, where the session has been recovered/recreated, that state events (FSM Event State field) no longer exist. This field is re-populated as new state changes occur.

 

 

Appendix J
VLANs

 

 

This appendix provides information on configuring an enhanced, or extended, service. The product administration guides provide examples and procedures for configuration of basic services on the system. You should select the configuration example that best meets your service model before using the procedures in this appendix.

This appendix includes the following sections:

•

Overview

•	Creating VLAN Tags

•	Configuring Subscriber VLAN Associations

Overview

Virtual LANs (VLANs) provide greater flexibility in the configuration and use of contexts and services.

They are configured as “tags” on a per-port basis and allow more complex configurations to be implemented. The VLAN tag allows a single physical port to be bound to multiple logical interfaces that can be configured in different contexts. Therefore, each Ethernet port can be viewed as containing many logical ports when VLAN tags are employed.

Important: VLANs are supported in conjunction with subscriber traffic ports on Ethernet line cards. The system supports the configuration limits for VLANs as described in the Engineering Rules appendix of this guide.

Creating VLAN Tags

Use the following example to create VLANs on a port and bind them to pre-existing interfaces. For information on creating interfaces, refer to the System Element Configuration Procedures chapter of this guide.

config

  port ethernet <slot/port>

     no shutdown

     vlan <vlan_tag_ID>

     no shutdown

     bind interface <interface_name> <context_name>

     end

Notes:

•	Optional: Configure VLAN-subscriber associations. Refer to the Configuring Subscriber VLAN Associations section for more information.

•	Repeat this procedure as needed to configure additional VLANs for the port.

Verify the port configuration – ASR 5000

Run the following command to verify the port configuration:

show port info <slot/port>

An example of this command’s output is shown below:

Port: 17/1

Port Type : 10/100 Ethernet

Description : (None Set)

Controlled By Card : 1 (Packet Accelerator Card)

Redundancy Mode : Card Mode

Redundant With : 33/1

Physical ifIndex : 285278208

Administrative State : Enabled

Configured Duplex : Auto

Configured Speed : Auto

MAC Address : 00-05-47-01-11-00

Link State : Up

Link Duplex : Unknown

Link Speed : Unknown

Untagged:

Logical ifIndex : 285278209

Operational State : Down, Active

Tagged VLAN: VID 10

Logical ifIndex : 285278210

VLAN Type : Subscriber

Administrative State : Enabled

Operational State : Up, Active

Number of VLANs : 1

Notes:

•	Optional: Repeat this configuration as needed to configure additional ports.

•	Optional: Configure VLAN-subscriber associations if needed.

•	Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

Configuring Subscriber VLAN Associations

Subscriber traffic can be routed to specific VLANs based on the configuration of their user profile. This functionality provides a mechanism for routing all traffic from a subscriber over the specified VLAN. All packets destined for the subscriber must also be sent using only IP addresses valid on the VLAN or they will be dropped.

RADIUS Attributes Used

The following RADIUS attributes can be configured within subscriber profiles on the RADIUS server to allow the association of a specific VLAN to the subscriber:

•	SN-Assigned-VLAN-ID: In the Starent VSA dictionary

•	SN1-Assigned-VLAN-ID: In the Starent VSA1 dictionary

Important: Since the instructions for configuring subscriber profiles differ between RADIUS server applications, this section only describes the individual attributes that can be added to the subscriber profile. Please refer to the documentation that shipped with your RADIUS server for instructions on configuring subscribers.

Configuring Local Subscriber Profiles

Use the configuration example below to configure VLAN associations within local subscriber profiles on the system.

Important: These instructions assume that you have already configured subscriber-type VLAN tags according to the instructions provided in the Creating VLAN Tags section of this appendix.

config

  context <context_name>

     subscriber name <user_name>

        ip vlan <vlan_id>

        end

Verify the subscriber profile configuration

Use the following command to view the configuration for a subscriber profile:

show subscriber configuration username <user_name>

Notes:

•	Repeat this command for each additional subscriber.

•	Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.